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Abstract 


Assume we have a network of three or more players, each player in possession of some 
private input. The players want to compute some function of these private inputs, but in a 
way which protects the privacy of each participant’s contribution. Not all of the players can 
be trusted to do as they are instructed. The resources the players are given to accomplish 
their goal are communication—the ability to privately send messages to one another, or to 
broadcast messages to the community as a whole—and local computation. 

Many insightful protocols have been proposed for solving this problem of multiparty 
secure function evaluation. Building on Yao’s protocol for the case of two players [Ya86], 
Goldreich, Micali and Wigderson [GMW587] offered the first general protocol for this prob- 
lem, and they provided the paradigm on which a large body of successive work was based. 

Despite enormous progress, research on secure function evaluation has suffered from 
some serious shortcomings. First, though many protocols have been devised for solving the 
problem, what, exactly, these protocols accomplish has not been fully understood. In fact, 
no rigorously specified and generally accepted definitions have been proposed in this field. 
Second, protocols for multiparty secure function evaluation could be extremely inefficient, 
the main cause being that they required an unbounded (and usually large) number of 
communication rounds, 

We address both of these points, carefully crafting definitions which satisfactorily deal 
with the myriad of issues lurking here, and offering a new protocol for multiparty secure 
function evaluation—one which categorically improves the complexity requirements for this 
task. The new protocol completely divorces the computational complexity of the function 
being collaboratively computed from the round complexity of the protocol that evaluates 
it. Using this approach, we show that a rigorously-specified and extremely strong notion 
of secure function evaluation can be achieved by a protocol which requires only a fixed 
constant number of rounds of interaction. This result assumes only the existence of a 
one-way function and that the majority of the participants to the protocol behave correctly. 
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CHAPTER 1 


Introduction 


This thesis is concerned with doing correct computation in ways that preserve people’s 


privacy. We begin with some motivating examples. 


1.1 Examples of Protocol Problems 


Millionaires problem (Yao, [Ya82a]). Two millionaires wish to find out who is richer, though 
neither is willing to reveal the extent of his fortune. Can they carry out a conversation which 
identifies the richer millionaire, but doesn’t divulge additional information about either’s 
wealth? 


Coin flipping problem (Blum, [B182]). How can Alice and Bob, speaking to one another 
over the telephone, agree on a random, unbiased coin flip—even if one of them cheats to 
try to produce a coin flip of a certain outcome? 


Oblivious transfer problem (Rabin, [Ra81]). Is it possible for Alice to send to Bob a com- 
posite number n in such a way that, half the time, Bob gets just n, while, the other half of 
the time, Bob gets n together with a factorization of n? Alice should have no idea which 
of these two possibilities has occurred. 


Mental poker problem (Shamir, Rivest and Adleman, [SRA81]). A group of cryptographers 
want to play a game of poker-——over the telephone. The stakes are high, so Alice becomes 
uneasy when Bob begins, “Alright, Alice, I’ve just shuffled a deck of cards—really I have— 
and now I’m dealing you your hand. You’ve got a 30, a 10@,a 76, a J&, and a 5d&...” 


Digital voting problem (Benaloh and Fisher, [BF85]). Is it possible for a group of computer 
users to hold a fair election on a computer network? The election should enforce the 
“one-man, one-vote” constraint, and should respect the privacy of each participant’s vote, 
revealing only the correctly computed tally. 
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Office assignment problem (Disgruntled staff, [MIT]). The n graduate students are thrown 
into disarray when suddenly told that they should pair themselves off into n/2 two-person 
offices. (Assume n is even.) Each student 7 has a list of ‘like;-values specifying his will- 
ingness to share an office with each other student j7. The students want their preferences 
taken into account, despite the fact that it would be more than a bit tactless for students to 
publish these lists! The students agree that the quality of a room assignment M, considered 
as a partition of the students into n/2 two-elements subsets, is reasonably well measured 
by wm = Lgij}ea min {‘like; ,/like;}. Now all the students want to do is to collaboratively 
compute an M that maximizes the value wy while simultaneously respecting the privacy 
of their individual ‘like; values ... 


1.2 Secure Protocols 


The problems above illustrate several variations in the goals one may have for carrying 
out a collaborative computation in a privacy-preserving manner. The following possibilities 
should be singled out: There may be two parties or there may be many. The result of the 
computation might be a single value, known to all players, or it might be a private value for 
each player. What is being collaboratively computed may be a computationally simple task 
or a computationally intensive one. What is being collaboratively computed may depend 
deterministically on the each player’s initial state, or it may depend only probabilistically 
on this. And the problem being solved might naturally be considered as a function, or— 
following the notion of Goldreich, Micali and Wigderson [GMW87]—it may be something 
which is not naturally considered as computing a function, a more “game-like” problem.’ 


The general notion of a secure protocol encompasses all of these possibilities. Each 
participant is willing to divulge some information pertaining to his own initial state in 
exchange for learning some information influenced by other participants’ initial states. A 
player’s willingness to participate in the protocol is based on the promise that the protocol 
will not only correctly compute what it is supposed to compute, but it will also protect the 
privacy of each player’s own contribution. We shall take seriously the notion that the job 
of the cryptographer is both to make good on this promise, and to precisely elucidate its 
meaning. We will do this in the general setting which we now describe. 


"TGMW87] uses the phrase “playing a mental game” to describe the problem of implementing on a 
communication network an n-party game of partial information—without recourse to a trusted party. This 
is the problem of allowing a progression in time of states of a system, certain aspects of each state known to 
various players, other aspects of the current state known to no one. In this viewpoint, computing a function 
by executing a Turing machine computation on inputs held by the various players is just one simple type of 
game that a group of players may wish to play. 
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1.3. Secure Function Evaluation 


Of the various “types” of secure protocols exemplified by our sample problems, we will 
limit our discussion in this thesis to multiparty secure function evaluations. Informally, we 
have n > 3 parties, 1,...,. Each party 7 has a private input, z;, known only to him. 
The parties want to correctly evaluate some function f on their private inputs—that is, to 
compute y = f(1,...,2n)—while maintaining the privacy of their own individual inputs. 
That is, they want to compute y without revealing more about their inputs than this value 
implicitly reveals. The players task of securely computing the function is made particularly 
difficult by the presence of bad players, who may do their utmost to compromise a good 
player’s privacy or disrupt the correctness of the collaborative computation. 

An enormous variety of computational tasks that one might wish to perform in a privacy- 
preserving manner can naturally be expressed as multiparty function evaluations. Still, we 
note that a multiparty secure function evaluation specializes the general notion of a secure 
protocol in two ways: by insisting that there be three or more players; and by demanding 
that what the players are trying to do is to compute some (deterministic) function. From 
our initial list of examples, the digital voting problem and the office assignment problem 
are multiparty secure function evaluations, while the remaining problems are not. 

There is good reason to limit our discussions to multiparty secure function evaluations. 
As to our insistence on there being three or more players, it turns out that what is achiev- 
able in the two-party case and what is achievable in the multiparty case are qualitatively 
very different. In fact, for achieving the strongest notion of security, one needs to have 
three or more participants.” As to excluding “game-like” computations, this simplifies our 
exposition, distilling the “core” of the problem of secure protocols without the extraneous 
complications. 


1.4 The Accomplishments of a Decade 


It is one of the major triumphs of modern cryptography that the idea of performing secure 
function evaluation has not only been conceived, but, also, protocols have been offered for 
this ambitious goal. Let us review some of the most important advances. 


TWO PARTY COMPUTATION. The consideration of the millionaires problem, the coin flip- 
ping problem, the oblivious transfer problem, the mental poker problem, and other specific 


Intuitively, when two parties communicate with one another over a clear communication channel, every- 
thing each player sends out to the other player is known by every player in the system. This “symmetry” 
means that there is no “partial knowledge” that can be exploited for the design of clever protocols, and, 
consequently, severely limits what can be securely computed by two parties communicating over a clear 
channel. 
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computational problems led to Yao’s recognizing that there is a general problem to be solved 
here—the problem of secure function evaluation for two or many players [Ya82a]. 

The task of devising a protocol to securely evaluate an arbitrary function seemed enor- 
mous. But in 1986, Yao proposed a protocol for exactly that, for the special case of n = 2 
parties, under a specific cryptographic assumption (that factoring is hard). Yao’s proto- 
col made important use of the oblivious transfer primitive [Ra81], and it inaugurated the 
“garbled circuit” approach, which will be crucial for us. 

Secure two-party computation has been investigated extensively by Kilian [Ki89]. He 
offers a protocol for secure two-party computation and proves precise claims about its prop- 
erties. Instead of making a number theoretic assumption, Kilian achieves his results under 
a model of computation which supports a simple abstract primitive—oblivious transfer. 

In a two-party computation, if one of the parties stops speaking before the protocol 
is specified to end, we would like that he does not for his silence earn an unfair informa- 
tion advantage over the other party. Yao first brought to light this consideration [Ya86]. 
Strengthening what a two-party computation should accomplish to be called “secure,” Gold- 
wasser and Levin investigate just how fair a two-party computation can be, and they show 
how to achieve such a high standard of fairness [GL90]. Their ideas are not only applicable 
to two-party computation, but to multiparty computation when half or more of the players 
are bad. 


MULTIPARTY COMPUTATION. In 1987, Goldreich, Micali and Wigderson proposed a protocol 
for solving the problem of multiparty secure function evaluation, and problems even more 
general than that [GMW87]. Their protocol was designed to overcome the influence of bad 
players, as long as they were in the minority. Significantly, it provided the paradigm on 
which successive solutions were based, a paradigm which is described Section 3.1. 

The protocol of Goldreich, Micali and Wigderson, as with Yao’s protocol, requires a 
complexity-theoretic assumption (a trapdoor permutation, say). The assumption is used 
in several places: to provide for private communication between pairs of players; to permit 
oblivious transfer between pairs of players; and to implement the “garbled circuit” computa- 
tion of Yao’s two-party protocol. In 1988, several workers managed to banish the complexity 
assumption of the [GMW87] protocol by positing a richer communication model, in which 
private communication was provided for by the model itself. Under this richer model of 
computation, Ben-Or, Goldwasser and Wigderson [BGW88], and Chaum, Crépeau and 
Damgard [CCD88] proposed multiparty protocols which made no cryptographic assump- 
tions and were designed to overcome the influence of bad players, as long as they constituted 
fewer than a third of all of the players. 

Besides achieving error-free secure distributed computation, the protocol of [BGW88] 
demonstrated the power of the arithmetization of Boolean computation—the power of work- 
ing over a finite field, instead of the Boolean domain, and exploiting its algebraic structure. 
It inaugurated the use of error correcting codes in this context. The arithmetization of 
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Boolean computation has subsequently proven important in a variety of contexts. 


EXTENDING THE PROTOCOLS ABOVE. The fault tolerance of the [BGW88] and [CCD88] 
protocols was subsequently improved.? Through the development of a new verifiable secret 
sharing scheme, Rabin and Ben-Or [RB89] managed to match the fault-tolerance of the 
[GMW87] protocol under the communication model providing both broadcast and pairwise 
private communication. 

The paper of Galil, Haber and Yung (GH Y87], among other contributions, made several 
improvements to the [GMW687] protocol, one idea from which we will make use of; see 
Section 3.1. 


WORK WHICH MADE THE PROTOCOLS ABOVE POSSIBLE. A large number of ideas had to 
be in place before the protocols above could be conceived. These ideas include the notion 
of secret sharing and verifiable secret sharing [Sh79, CGMA85], oblivious transfer [Ra81], 
probabilistic encryption [GM84], zero-knowledge proofs [GMR85, GMW86], and the slow 
revelation of a secret [B182, LMR83, BG89]. 


1.5 Limitations of Earlier Work 


LIMITATIONS ON DEFINITIONS. The papers of the last subsection describe protocols. It is 
clear that these protocols have some remarkable properties. Of course the various authors 
have worked to describe what these properties are, offering definitions, to varying degrees 
of explicitness. But, in our view, no one succeeded in devising satisfactory definitions for 
the general problem at hand. 

Not having satisfactory definitions for secure protocols is a major problem. Cryptogra- 
phers have seen, in contexts like digital signatures, how a lack of well-planned definitions 
can lead them astray.* Without good definitions, there are no proofs, there can be no full 
understanding of the problem, and, eventually, no one understands what anything really 
means. 

For secure function evaluation, definitions must be crafted with extreme care. Otherwise, 
they are likely to admit as “secure protocols” some protocols which we would like not to 
have this status; or they may exclude as being “secure” protocols which ought to be called 
secure; or protocols which achieve the definitions may fail to provably have properties one 
would expect a secure protocol to enjoy; or the definitions may not capture the appropriate 
intuition; or they may be too complicated to understand; and so forth. 


3For error-free secure computation, the fault tolerance achieved by the [BGW88] protocol is, in fact, 
already optimal. 

“Central contributions in getting this notion straight were due to Diffie and Hellman [DH76], Goldwasser, 
Micali and Yao [GMY83], and, finally, to Goldwasser, Micali, and Rivest [GMR88]. The notion of digital 
signatures is now well understood. 
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Thus —as I see it— a large body of beautiful notions and protocols has sat atop rather 
murky foundations. As a consequence of the lack of agreement on definitions, the protocols 
which were offered were to a large extent offered without proof that they accomplished any 


rigorously-specified set of goals. 


LIMITATIONS ON THE PROTOCOLS. There was another problem as well: all of the multiparty 
protocols which had been devised were computationally infeasible. To a large extent, this 
was because each minute step of the computation the players were interested in carrying 
out would manifest itself as additional communication rounds between the players. This 
is a serious problem, because in a network of communicating parties, such back-and-forth 


communication is usually the most costly resource. 


1.6 Contributions of this Thesis 


This thesis makes three contributions in the design and understanding of secure protocols. 


> First, we define the notion of secure function evaluation, in detail and with care never 
before attempted. The definitions given in this thesis are for secure function evaluation 
under the communication model that players may speak privately to one another in pairs, 
or they may broadcast messages to everyone. More general notions in the same spirit as ours 
will be described in [MR91]. It should be emphasized again that achieving good definitions 
in this domain is a very tricky matter; it is here that the most delicate issues arise, and, 
indeed, the definitions given here is a part of definitional work nearly two years in the 
making. 


> Second, we offer a new protocol for multiparty secure function evaluation. This protocol 
has a major advantage over all previous protocols: it runs fast, in the sense of requiring little 
back-and-forth communication among the players. In fact, the protocol uses just a (fixed) 
constant number of rounds. This independence of the round complexity of the protocol 
from the computational complexity of the underlying function being evaluated is in sharp 
contrast with previous protocols, which used a number of rounds which grew directly with 
the circuit complexity of the function being evaluated. Not only does reducing the rounds 
to a constant amount to overcoming the main barrier to making secure protocols practical, 
but it also provides a key insight about the problem itself. Additionally, the new protocol 
is easier to analyze and make provable assertions about than previous complexity-theoretic 
proposals. 


> Third, we prove that the formal notion of secure computation described is in fact achieved 
by the protocol presented, under the sole assumption of the existence of a one-way function, 
and that the majority of the players behave honestly. The later assumption is not really 
a limitation, but a necessary consequence of the “strong” notion of security which our 
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definitions are designed to capture.® To prove our protocol secure, we assume the correctness 
of some previous work on secure multiparty function evaluation. What exactly is assumed 
and what is achieved is stated precisely as Theorem 4.1.1, and Theorems 4.3.1 and 4.4.1, 


respectively. 


Taken together, this research puts secure function evaluation on much firmer footing, and 


provides direction for the continued development of the area. 


1.7 Related Work 


Concurrent with the definitional work of Kilian, Micali and Rogaway [KMR90], Gold- 
wasser and Levin independently proposed interesting definitions for secure function evalu- 
ation [GL90]. It is early to assess how their definitions compare with ours. 


Early in our research we shared definitional ideas with Beaver, who later pursued his 


own ones in [Be9]]. 


1.8 Organization and History of Thesis Results. 


ORGANIZATION OF THESIS RESULTS. Paralleling the three contributions of Section 1.6, 
the notion of security is described in Chapter 2; the constant-round protocol is given in 
Chapter 3; and the proof that it is indeed a secure protocol is given in Chapter 4. 


PUBLICATION HISTORY OF THESIS RESULTS. The definitions of Chapter 2 are a special 
case of notions developed by Micali and Rogaway. An extensive paper investigating these 
notions is currently undergoing revision [MR91]. 

At an earlier stage of this research, Micali and Rogaway collaborated with Kilian in 
developing definitions for secure function evaluation. The fruits of this collaboration are de- 
scribed in [KMR90]. The definitions offered here are more stringent than those of [KMR90], 
attempting to capture elements of the “ideal evaluation” of a function which this earlier work 
did not attempt to capture. (See Section 2.4.1 for an explanation of the ideal evaluation of 
a function f.) 


Intuitively, when half or more of the players may cheat, certain functions can be computed “more and 
more correctly” only as you spend “more and more time trying to compute them.” There is never a point 
in time in which the function is computed “totally correctly.” Since we want a strong notion of security, 
in which our protocols should stop, at some fixed point in time, with everyone knowing exactly what they 
should know, we are forced to accept that there should be fewer than half faulty players. 

The first protocol to show how time spent interacting could be traded for increased correctness was due to 
Luby, Micali and Rackoff [LMR83], in the context of the coin flipping problem. Indeed it is necessary to pay 
for correctness with time for the coin flipping problem, as demonstrated by Cleve [C185]. Goldwasser and 
Levin, following Beaver and Goldwasser, have investigated just how strong a notion of security is achievable 
when there is a dishonest majority [BG89, GL90}. 
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The constant-round protocol of Chapter 3 was developed jointly with Micali. Having 
heard from Beaver that he too had developed these same results, we thought it fit to produce 
a jointly authored proceedings version. However, written documentation subsequently pro- 
vided to us by Beaver was only mildly related to our constant round-protocol [Be88b]. What 
we describe in Chapter 3 is a revised and simplified version of the protocol in [BMR90]}. 


The contents of Chapter 4—the proof of security of the constant-round protocol—has 


not appeared elsewhere. 


CHAPTER 2 


The Notion of Secure Computation 


To a cryptographer, security means defeating an adversary. The stronger the adversary 
that can be defeated, the more secure the cryptosystem. Thus cryptographers try to dream 
up nastier and nastier adversaries, and then prove (sometimes under various assumptions) 
that these very strong adversaries are harmless nonetheless. 

In each context, one must carefully define what the adversary can do, and in what sense 
the adversary is rendered powerless. 

In this chapter, we carefully do this, in the context of secure function evaluation. We 


begin with a brief overview of our goal. 


2.1 Overview 


For secure function evaluation, achieving security means overcoming the influence of those 
who would try to compromise a player’s privacy or disrupt the integrity of the collaborative 
computation. The stronger this adversary, the more difficult to overcome the effect of her 
activities, and the more meaningful the resulting notion of security. Specifying what a 
protocol we call secure must accomplish consists of specifying the abilities of the protocol’s 
participants, specifying the abilities of the adversary, and saying in what sense the adversary 
is rendered harmless. 


POWERFUL ADVERSARIES. The adversary we will consider will be extremely strong—the 
strongest “reasonable” adversary we can postulate. Roughly, the adversary is able to corrupt 
players at any time she wishes. When a player is corrupted, the adversary learns the state of 
the player at the time at which he was corrupted, and all future computation the corrupted 
player was responsible for is now controlled by the adversary. Effectively, the player has 


been turned into the adversary’s loyal agent. To give our adversaries even more power, 
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we assert that even though our protocols are synchronous (communication occurs in fixed 
increments of rounds), the adversary is granted a certain amount of asynchrony in her ability 
to corrupt players. The only restrictions placed on the adversary is that there may be a 
bound on the number of players whom she is able to corrupt, and (for complexity-theoretic 
security) her local computation time must be “reasonable.” 

Regarding an adversary as a single agent, rather than many, makes the resulting notion of 
an adversary stronger, effectively permitting a maximal degree of surreptitious cooperation 


among the maliciously faulty participants to a protocol. 


DEFEATING AN ADVERSARY. To develop the notion of what it should mean to defeat such 
an adversary, we imagine an ideal protocol, in which computation is carried out by some 
external, trusted party. Privacy and correctness are non-issues in this scenario because the 
model provides for correct and private computation. Defeating an adversary ought to mean 
that the computation carried out by the protocol under attack by the adversary mimics the 
computation by the ideal protocol under attack by the adversary as closely as possible. In 
other words, a secure protocol succeeds in simulating the existence of an external trusted 
party, while actually trusting no one. 

Making this precise entails specifying in what sense the computation of a secure protocol 
is “just like” the computation of the function by a trusted party. A secure protocol should 
be “just as private” and “just as correct” as with a trusted party. To define privacy, we 
choose a simulation-based viewpoint, motivated by Goldwasser, Micali and Rackoff’s ideas 
developed in the context of zero-knowledge proof systems [GMR85]. Basically, a protocol 
is deemed private if for any adversary, what she learns when executing with a protocol is 
nothing but a sample point of a distribution which she is entitled to sample. Correctness 
is then “interwoven” into the notion of privacy: the simulator existentially guaranteed for 
privacy is the principal ob ject through which correctness is defined. We do this in a manner 
which preserves the idea present in the ideal protocol of sending a value off to the external 
trusted party, and then each player—even the bad players—getting (the right) value back 
from this agent. 


GETTING THE NOTIONS RIGHT. In the context of secure protocols, “getting the notions 
right” is extremely delicate. Definitional issues are tricky both because of the inherent 
complexity of the setting (a distributed protocol under attack by a powerful adversary is 
a complicated object!), and because of the severity of the constraints one wants to put on 
the behavior of the protocol in the presence of the adversary (that is, one wants to ensure 


‘In particular, we permit rushing—the ability of the adversary to corrupt a player at the end of round r 
and use this information to decide on additional players to corrupt during round r. Information gleaned 
from these players may in turn motivate additional corruptions, and so forth, until the adversary is done 
corrupting players for now. Then the outgoing messages are constructed and sent out on behalf of the 
corrupted players. All of these activities are completed before the beginning of round r+ 1. 
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the highest possible standard for correctness as well as for privacy). Too weak a notion of 
security and “secure protocols” begin to pop into existence that one would not like to call 
secure; too strong a notion and “secure protocols” virtually drop out of existence. 

Besides achieving the right balance between definitions which are too strong and too 
weak, there are a host of other issues in the crafting of good definitions. For example, 
composability and reducibility properties are important. Uniformly being able to treat 
complexity-theoretic security and information-theoretic security is desirable. Simplicity is 
very important. Model independence. And there are many other concerns. Successful 
definitional work refines one’s intuition about security, protocols, and adversaries, leading 
to substantially improved understanding. 


2.2 Preliminaries 


Before specifying what it means that our adversary “learns nothing,” and that our protocol 
“computes something,” we must introduce some basic language to talk about these things. 
Some of this is standard, but much has been tailored to our specific goal of defining secure 
computation. 


2.2.1 Notation 


SETS, STRINGS, LANGUAGES, AND FUNCTIONS. An alphabet is a finite set. Fix the alpha- 
bet © = {0,1}. For 6 € ¥, we call b a bit and we let b denote its complement. A string 
is a finite sequence of characters from some alphabet, and an infinite string is an infinite 
sequence of characters over some alphabet. A language is a set of strings. 

If A is a set, then A” denotes the set which is the n-wise Cartesian product of A 
with itself. Thus &” is the language of strings of length n over alphabet ©, and we let 
x* = U, =” denote the set of all strings over L. We let L” denote the set of infinite strings 
over alphabet ©. The empty string (i.e., the length-0 sequence of characters) is denoted 
by A. For A a set, fix the convention that A° is the singleton language {A}. The notation 
1” represents n written in unary. If we write zx € D* where z is apparently not composed 
of characters of the alphabet © (e.g., 2 = 11#0m), then it is understood that the string z is 
encoded over © in some natural manner. If A is a set, 24 is the set of all subsets of A. 

If x and y are strings, xy denotes their concatenation. If 2 = a,---a, is astring, a; € L, 
then 2[i:7] (where i < 7) is the substring a;---a;. If ec = a,---a, is a string, a; € D, then 
Isb(z) = ay. For x,y € d*, |x| = |y|, e@y is the bitwise exclusive-or (KOR) of these strings. 
The NAND operator on bits give the negation of their conjunct. 

When a symbol denotes a string or an infinite string, use of the same symbol with 
a subscript denotes the indicated character. This convention holds even if the symbol 
denoting the string already bears a subscript. For example, if r; is a string or an infinite 
string, then 7;; is the first character of 7;. 
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The set of nonnegative integers is denoted N = {0,1,2,...}, and R is the set of real 
numbers. If a and 6 are integers, a < 6, we let [a..b] denote the set of integers between 
a and 5, inclusive. By [a..cc) we denote the set of all integers greater than or equal to a, 
and by [a..co] we denote the set of all integers greater than or equal to a, together with a 
point “oo”. This set is ordered in the natural way, with all numbers n < oo. For A and B 
ordered sets, the set A x B is ordered according to (a,b) < (a’,0’) if either a < a’ ora =a’ 
and b < 0’. 

If A and B are sets, A — B denotes the elements of A which are not in B. 

For f: A > B a function, f is automatically extended to a function on subsets of A 
according to f(X) = {f(z): 2 € X}. For f: A— Ba function, f-'(y) = {z: f(x) = y}. 
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Vectors. As usual, we denote a vector by a letter topped with an arrow symbol, 
The same letter without the arrow but with a subscript denotes the indicated component. 


h 


For example, if # is a vector, z; is its i** component. An n-vector ¢ has n components, 


Z1,---,2y- If Z and Ff are n-vectors, #7 denotes the n-vector whose i** component is 2;y;. 
Fix n, and let T C [1..n]. Then we write T for [1..n] — T. If Z is an n-vector and 
T C [1..n], we define the tagged vector xp = {(i,2;): 1 € T}. (That is, rp keeps track of 
the indices as well as the values.) If Z and # are n-vectors and T C [l..n], then 27 U rp 
can be regarded as an n-vector 7 where y,; = x; ifi € T and y; = x, otherwise. 
For f: (D£)" > (Z')" and T C [1..n], fr(£) is the function defined by fr(Z) = (f(Z))r- 
(That is, fr(£) is the tagged T-coordinates of the image of # under f.) 


PROBABILITY. All probability spaces we will be concerned with have underlying set 2 = &", 
and o-field 2°". Thus we won’t distinguish between a probability space and the probability 
measure of a space. Our probability measures will all have finite support (i.e., the measure 
is nonzero only on finitely many points). The probability of an event EF C D* with respect 
to some measure p is written Prob, [EZ], or simply Prob[£] when the measure yz is under- 
stood. If E is an event of some probability space, EF is the event which is the set-theoretic 
complement of E£ in the underlying set. 

A random variable is any function (not necessarily real-valued) on the underlying set of 
a probability space. The expectation of a real-valued random variable X is denoted EX. 

By U;, we denote the uniform distribution on U*, that is, U; is the probability measure 
which assigns mass 2~* to each string of length k, and assigns mass 0 to all other strings. 


2.2.2 Basic Notions 


This subsection defines some notions fundamental for stating our results: these are the 
notions of function families, circuits, negligibility, and ensembles. 


FUNCTION FAMILIES. A finite function is a map fne : (D')” > (2')", or a map fre : 
(=5)" = D!. The former is a vector-valued finite function, while the later is a string-valued 
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finite function. 

Since we are devising definitions tailored for distributed computation by three or more 
parties, we consider families of functions, each a function of three or more strings. Suppose 
LC &*, with each c € L specifying values n, > 3, £.,/, > 0, in some natural manner. Let 
f ={f-} be a collection of functions, one for each c € L. If each f, is a vector-valued finite 
function f, : (D%:)"= — (X':)"«, we say that f is a vector-valued function family; if each f, is 
a string-valued finite function f, : (Z‘)"* — L':, we say that f is a string-valued function 
family; in either of the above two cases we say that f is a function family. 


Circuits. A circuit C is a computing device specialized for computing a function from 
a fixed number of bits to a fixed number of bits. It is a (finite) labeled directed acyclic 
graph. Each node is labeled by a symmetric Boolean operator drawn from some fixed set 
of Boolean operators, such as AND, OR, XOR, and their negations. Input nodes (those 
with in-degree zero) are labeled 2;,...,2%;, and output nodes (those with out-degree zero) 
are labeled y,,..., Yo- 

Circuits provide a convenient encoding for finite functions. A circuit C on i inputs 
and o outputs computes a function C: X? — DH? in the natural way. For i = né,o=nl,C 
can be regarded as computing a vector-valued finite function C : (X*)" — (X')". Fori= né, 
o=1, C can be regarded as computing a string-valued finite function C :(Z4)” > D!. 

If C is a circuit, then |C| is its size—the number of gates in C plus the number of wires 
in C, say—and depth(C) is its depth—the length of a longest path from an input node to 
an output node. If C’ is a circuit, we also write C to denote a string describing it in some 
standard encoding. 


WHAT Is FAST? We adopt the notion that the polynomiality of an algorithm captures its 
running in a “reasonable” amount of time. In this thesis, “polynomial” will always mean a 
nonnegative-valued polynomial in a single variable. 

It will be convenient for us to speak of the time complexity of algorithms which have 
infinite strings as inputs. To allow such discourse, we always measure the time complexity of 
a function in terms of the length of its first argument, and we assume that each argument to 
an algorithm can be efficiently scanned from left to right. More precisely, let 21, 22,...,;2m 
be finite or infinite strings, the first of which is a finite string. We say that a string-valued 
function M on such tuples of strings (11,...,2m) is polynomial-time computable if there ex- 
ists a polynomial Q and a Turing machine M, having m input tapes, such that M computes 
M(#1,22,.--,;2m) Within Q(|z,|)-time steps when M is begun in its initial configuration 
with its i input tape initialized to the string 2;. 


WHAT IS SMALL? We will say that a function ¢€: N — R is negligible if it is nonnegative 
and vanishes faster than the inverse of any polynomial: for any c > 0 there exists a K € N 
such that «(k) < k-° for all k > K. A function «(k) which is not negligible is called 
nonnegligible. 


24 


There is, of course, some arbitrariness in this notion of negligibility. An alternative 
advocated by Levin (e.g., [Le85]) says that a function is negligible if it vanishes faster than 
the inverse of any function in some fixed resource class R, where R is required to satisfy 
certain properties. Fortunately, the notions we develop here are essentially independent of 


the particular definition selected for negligibility. 


2.2.3 Indistinguishability of Ensembles 


A central notion in defining secure protocols is indistinguishability, as introduced by [GM84] 
in the context of encryption. (The notion has also proven crucial for the complexity theoretic 
treatment of pseudorandom generation [Ya82b] and for zero-knowledge proofs [GMR85].) 
Essentially, it captures the fact that two families of probability spaces can be (asymptoti- 
cally) so close as to be considered insignificantly different. To say this exactly requires some 
specialized language—the notion of a distinguisher and of a probability ensemble. The 
reader who wishes a bit more discussion about this notion may consult [GMR85] (pages 
191-193). 


DISTINGUISHERS. A distinguisher is our formalization of a “judge” who votes to decide 
among two competing alternatives. As will be discussed shortly, our notion of a distinguisher 
is a “nonuniform” one. 

A distinguisher D* is an (always halting) probabilistic algorithm, D, together with an 
infinite “advice” string, a. The algorithm D takes one or more (possibly infinite) strings, 
Z1,22,..., and uses its infinite sequence of random bits, rp, and its infinite string, a, to 
compute a value D(21,22,...,a,7p) € {0,1}. A distinguisher D* is polynomial-time if D 
is polynomial-time. (Recall that this means polynomial-time in the length of the first 
argument.) 


ENSEMBLES. If £ = {L, : k € N} isa family of languages, then an ensemble E (over L) isa 
collection of probability measures on %*, one for each (k,w) € N x L,; that is, FE = {Ey (w) : 
kKEN,we€ Ly}. The argument k is called the index of the ensemble F, the argument w is 
called the parameter of E, and CL is called the parameter set of E. As the index k is always 
drawn from the indez set N, we never specify it, writing E = {E,(w): w € L,} to indicate 
an ensemble over £. When the parameter set of an ensemble is understood and there is 
no danger of confusion, we refer to an ensemble by writing the symbol “€” in front of its 
“generic element”—that is, we simply write €E,(w) instead of {F,(w): w € Ly}. 

The above notion of an ensemble applies only to distributions on strings. However, the 
notion is trivially extended to any other domain whose elements can be canonically encoded 
as strings. We will thus speak of ensembles on other domains, where it is understood that 
there is, implicitly, a fixed encoding of domain points into strings. 

If E and E’ are probability ensembles over a common parameter set C = {L,;}, then 
E x E’ is an ensemble over £, where points in &* encode pairs of points in L* by some 
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fixed, natural encoding. This ensemble is defined by asserting that Probiexe,(w)[(2, 2’)] = 
Prob z,(.)[2] - Probg:(.){z']. The notion generalizes in the obvious way to arbitrary finite 
products. The notation E” denotes an ensemble which is the n-wise product of FE with 
itself. 

If f : &* + &* is a function on strings and F is an ensemble, then f(£) is an ensemble 
in the natural way, with Probcs(2)),(w)[2] = Probg,(uy)[f~*(2)). 

If €E,(w) is an ensemble and A = {A; C &*} is a family of events, we say that A occurs 
almost certainly if ek) = super, Probx,(«)[Ax] is negligible. 

Sometimes a simpler notion of an ensemble will do, ensembles which have no param- 
eter w. In this case, €F; is simply an N-indexed family of probability measures on b*, 
and all subsequent definitions are made meaningful by interpreting the parameter set of the 
ensemble to be a collection of singleton languages. 

As an example of an unparameterized ensemble, €U;, is the ensemble of uniform dis- 
tributions on k-bit strings. As an example of a parameterized ensemble, fix c and define 
E,,(2,-++2,e) (for |z;| = 1) as the distribution on tuples (n, X1,---,X,-) given by first se- 
lecting n to be the product of two random k-bit primes, then selecting X; to be a random 
residue modulo n if 2; = 0, and selecting X; to be a random nonresidue modulo n of Jacobi 
symbol +1 if z; = 1. Then €F,(z) is an interesting ensemble over {L, = =**}. 


COMPUTATIONAL INDISTINGUISHABILITY. We now specify what it means for two ensembles 
to be indistinguishable to an observer with bounded computational resources. 


Definition 2.2.1 Let E and E’ be ensembles. We say that E and E’ are computationally 
indistinguishable, written EF ~ E’, if the ensembles are over the same parameter set L = {Ix}, 
and for every polynomial-time distinguisher D* 


e(k) = sup |ED(1", E,(w),w,a) — ED(1*, E,(w),w,a)| 
weL, 
is negligible. 


When we wish to emphasize the sequence of languages {£,} which parameterizes the en- 
sembles & and E’ we write E x E’. Two ensembles over the same parameter set £ which 
are not computationally indistinguishable are called computationally distinguishable. This 
is written EF # E’. 

The notion we have defined for computational indistinguishability is a nonuniform 
notion—possibly, the ensembles appear different to the resource-bounded judge only by 
virtue of the advice string a. Nonuniform notions of indistinguishability have more com- 
monly been defined by polynomial-size circuit families. We find the phrasing above more 
convenient, because it is more natural for an infinite string to be an input to an algorithm 
than to a circuit. 

Uniform notions of computational indistinguishability—where the distinguisher does not 
have benefit of the advice a—are also possible. In fact, all results of this thesis hold equally 


26 


in the uniform model. However, for economy of notions, we choose to describe only the 
nonuniform notion of security. Some reasons for favoring the nonuniform notion of security 


over its uniform counterpart are given in Section 2.3.3. 


> We remark that the following two variations of the concept of indistinguishability are 
possible without affecting which pairs of ensembles are indistinguishable and which are 
not. First, the distinguisher need not be probabilistic: the advice a can always be used to 
specify a “good” set of coin flips to use. Second, instead of saying that a single infinite 
advice string a is associated to the algorithm D, we could instead associate an advice string 
for each value k. To distinguish E,(w) from Ej(w), the distinguishing algorithm D would 
be given 1*, the sample point, the parameter w, and a,. To see that this “k-dependent 
advice” does not improve one’s ability to distinguish ensembles, note that, by the standard 
diagonalization method, an infinite sequence of infinite advice strings {a,} can be encoded 
into a single infinite advice string a in such a way that the overhead to read a bit a,[#] from 


the advice string a which encodes it is only quadratic in k and 7. 


STATISTICAL INDISTINGUISHABILITY. We define a stronger notion of indistinguishability, 
one that does not depend on the resource bounds of the observer. 


Definition 2.2.2 Let E and E’ be ensembles. We say that E and E’ are statistically 
indistinguishable, written E ~ E’, if the ensembles are over the same parameter set LC = {L,}, 
and for every distinguisher D°, 


e(k) = sup |ED(1*, E,(w),w,a) — ED(1*, Ey(w),w,a)| 
weL, 


is negligible. 


It is an easy theorem that ensembles €F,(w) and €E,(w) over {L,} are statistically indis- 
tinguishable if an only if e(k) = supyer, (Xorens |Probs,(.)[2] — Probg:(.)[z]) is negligible. 


2.3. Protocols and Their Adversaries 


In this section we describe not only the communication mechanism provided to the agents 
of a collaborative computation, but also the adversary which may attack these agents—for 
one has not described the behavior of a protocol until it is specified how it runs in the 
presence of the adversary. 

The adversary we consider is extremely strong, which makes our definition of security 
much more meaningful. On the other hand, given that secure protocols are non-trivial to 
find, we at least make them easier to write by providing a generous communication model. 
In essence, we allow each player both to privately talk to any other player and to talk 
“aloud,” so that all other players will agree on what was said and on who said it. 
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SUMMARY OF THE MODEL. The players (or processors) are the agents who wish to carry 
out the joint computation. The collection of players is the network, and the program that 
the players run is called a protocol. To be certain that a protocol can be easily described, 
each player runs the same program; it is made specific to the player who is running it by 
letting the player be aware of his own identity. The players have two resources at their 
disposal: the ability to compute locally, and the ability to communicate with one another. 
To communicate, the processors may talk privately to one another in pairs, or they may 
announce messages to the community as a whole. When they do broadcast a message, 
everyone knows who sent it. 

As a player computes, his computational state progresses in time. One might imagine 
that this computational state should progress as the communication rounds progress, but 
instead we formalize matters with a finer level of granularity, thinking of a processor as 
carrying out many computational steps within a single round. These steps consist of flip- 
ping a coin or applying some deterministic function to his computational state. When the 
round is over, the messages a player sends out to the other players are functions of his 
computational state, and the messages a player receives from other players—functions of 
their computational states—augment his computational state in a timely manner. 

Initially, each player knows only his own initial computational state. The information 
this contains is his identity, i, his private input, x;, and a string called the common input, c, 
which is shared by all of the players. The common input contains such information as 
the number of players in the network, n, and a description of the function they wish to 
compute, f,. 

For simplicity, we insist that players’ private inputs are all of the same length. While 
it is not important that all inputs be of the same length—this could be accomplished by 
padding the inputs which are too short—it is important that the players know a bound 
on the length of the longest possible private input. That this is a natural and reasonable 
restriction can be motivated as follows. One thing a player 7 learns about another player 7 
when interacting with him is the number of bits which were sent out by 7 and received 
by 2. For some functions, player 7 must send out at least as many bits as his private input 
is long—even if there were no privacy constraint at all. A convenient way to make sure 
that this degree of exposure of one’s input is not considered to be damaging is to say that 
bounds on input lengths were already known in advance by each player.” 

Our goal in this chapter is to properly define those protocols which are robust against 
the incorrect behavior of some of its participants. We adopt an extremely pessimistic view 
of how players may diverge from faithfully executing a protocol. Namely, we imagine that 
the players are not the only agents involved in the joint computation: also present is an 
adversary, who runs a program the players know nothing about. The unpleasant trait of 


?When this restriction is not made, the problem of secure computation changes radically in character. 
See [CGK90] for some work in this framework. 
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an adversary is her ability to corrupt players. When a player is corrupted, he is made the 
adversary’s loyal servant, with the adversary subsuming all communication and computation 
associated with the corrupted player. Additionally, the adversary is handed over the private 
state of the corrupted player at the time at which the player was corrupted. 

The computation proceeds in rounds. The adversary runs; then the players run; then 
the adversary runs; then the players; and so forth, until all the players have terminated. 
At this point, the adversary is given one last run, and then the protocol has terminated. 
Within each of these adversary and player rounds, a good deal of activity may go on—as 
players do computation, and the adversary computes and corrupts processors. 

We will be interested in how much the adversary can learn as a result of her activities, 
and what the good players compute, despite the interference of the adversary. To concretize 


these ideas, we now proceed more formally. 


2.3.1 Protocols 


PROTOCOLS FOR n-PARTIES. In this section we describe what a protocol for a fixed number 
of players is. Later we discuss protocols for arbitrary numbers of players. 

Recall that & is the binary alphabet, and words over this alphabet are indicated by 
writing that they belong to L*. However, we will sometimes indicate that words which 
are apparently not over the binary alphabet are to be considered as belonging to ©*-—for 
example, we might write 0f0*1 € 5*. When we do this, it is understood that the symbols 
which constitute the “expanded” alphabet over which our strings are drawn are encoded as 
strings over D* by some fixed, natural encoding scheme. 

In the definition that follows, the protocol P is the main object of interest. It specifies 
how the computational states of the players are to progress in time. Specifying a protocol 
means defining the map P. The interaction functions are the “glue” that allows applying 
the function P repeatedly to capture the network’s state progressing in time. 


Definition 2.3.1 An n-party protocol is a Turing-computable function 


Pie a OK Ee Se 
“~” “~ ~” 
common current new 
input state state 


A network interaction function is any of the following polynomial-time computable functions: 
1. a next-action function 7 : L* — {compute, flip-coin, round-done, protocol-done}, 
2. a broadcast messages function M : &* > &X*, 
3. a private messages function m: D* x [1..n] — &*, and 
4, an output function o: 4* > dX", 


A player configuration is an element of =* x S” x y* 
WY ww ed 


player’s coins history 
state remaining 
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NoTATION. In place of m(s;,7) we will write m;(s;). 


Discussion. The next subsection describes, formally, how a protocol runs. Here we give a 
sketch of this. 

To run a protocol, each player starts off in some initial computational state. Each player 
applies the next action function, 7, to his current computational state to see what he should 
do. If it says that he should compute, then the algorithm P is applied to the computational 
state to come up with a new computational state. If it says that he should flip-coin, then the 
player is given a random coin toss from his infinite sequence of random coins. The consumed 
coin then “vanishes” from the infinite sequence of future coin tosses. As long as the player 
computes or gets coin flips, the process continues. When the player is done with all of 
his activities for this round, this is indicated by 7 assuming the value round-done. When 
all the players are done computing in this round, their broadcasts and private messages 
are “delivered”—that is, these strings are properly appended to the computational states 
of other players. (This will be described in the next subsection.) The messages a player 
broadcasts and those he sends out privately to other players are determined by applying 
the functions M and m to his own computational state. Thus, even though these functions 
assume values before a player is done with a given round, their values are of no importance 
then. After all the messages are delivered, each player resumes running: the next action 
function 7 is again applied to his current computational state—the state that the processor is 
in after the messages he receives from other players have been appended to his computational 
state. When a processor is finished with all the activities he wishes to engage in for this 
execution of the protocol, instead of simply choosing a computational state in which 7 
assumes a value of round-done, he instead selects a computational state which 7 indicates 
protocol-done. At this point, the output function o defines the player’s private output; 
previous to this, the output function is not meaningful. The protocol terminates when 
every player is protocol-done. 

As the proceeding discussion suggests, a protocol P can only be run with respect to a 
fixed set of interaction functions. When combined with P, these interaction functions specify 
how a player’s computational state is to progress in time, affecting the computational states 
of other players in the network. Thus we might have considered a protocol to be a five-tuple 
(P,n, M,m, 0) consisting of the protocol algorithm proper and the collection of interaction 
functions. However, it is more convenient to require that the interaction functions be 
fixed functions, good for any protocol. This way, for example, protocols can more easily 
be composed with one another: there is no danger that two protocols employ different 
conventions on how processors communicate, say. 

We have not specified these interaction functions since the particular conventions chosen 
for defining them are not important. Each function should specify its range value in a natural 
and simple manner from its domain value. For example, with “(”, “)”, “(”, “)”, and “,” 


all being formal symbols, we might say that if s; contains one and only one occurrence of a 
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substring (17), then 7(s;) = compute if 7 = 1, n(s;) = flip-coin if 7 = 2, n(s;) = round-done 
if j = 3, and n(s;) = protocol-done otherwise; if s; contains one and only one occurrence 
of a substring (y), then M(s;) = p; otherwise, M(s;) = A; if 5; contains one and only one 
occurrence of a substring (1/,;), for j € [1..n], then m;(s;) = jj; otherwise; m;(s;) = A; 
and if s; contains one and only one occurrence of a substring [(], then o(s;) = ¢; otherwise, 
o(s;) = A. This was just an example of how the interaction functions could be defined; the 
specific choice of conventions is irrelevant. 

We have not described a player’s configuration. It captures his current computational 
state, his future coin tosses, and his history. The history is information associated to a 
player which is not relevant to the task at hand. The presence of the history is useful 
for properly dealing with protocol composition, and for proving certain properties of secure 
protocols. For example, when a protocol is called as a subroutine, the “saved state” which is 
irrelevant to the subroutine call is tucked away in the history. Since we will not be concerned 
with subroutine calls in this thesis, the saved state is of no real importance. However, we 
keep this information around because of its playing a significant role in the more general 
theory of secure protocols. 

We now define more formally how a protocol runs in the absence of an adversary. 


2.3.2 Executing Protocols in the Absence of an Adversary 


Notice how, in the formalism for a protocol, we have a fine level of granularity in how a 
protocol runs—all the way down to individual coins being tossed. We could have tried 
to be more succinct, letting a player’s computational state progress from round-to-round, 
with a player doing all the necessary computation “in one shot.” However, the approach 
selected turns out to be more symmetric with the natural way of phrasing the adversary’s 
behavior—she gets information repeatedly from the players within a single round. This 
approach also serves to emphasize that a player may choose to remember a coin toss or 
he may choose not to remember a coin toss, but—as we shall see when we discuss the 
adversary—a coin, once flipped, is not recoverable by the adversary except to the extent 
that it is stored in the player’s computational state. 

Thus we index the player configurations by two superscripts. The first index, r, is a 
counter for the round number. The second index, p, is the “micro-round” number, formal- 
izing this finer granularity as the protocol flips coins and does computation. We allow the 
micro-round to take on the formal value “oo”. If a player’s computation for round r is com- 
pleted at some micro-round p, then all subsequent computational states for micro-rounds 
during round r, including that at time (7,00), are fixed. This is notationally convenient. 


CONFIGURATION SEQUENCES. An n-party protocol P generates from n initial player con- 
figurations, (C?°,...,C)°), a sequence of configurations {C7’: i € [1..n],r € N,p € [0..co]}, 
which we now describe. 
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We remark that some configurations may fail to be defined by the recurrences below; 
this will be dealt with later. We note that the character r is somewhat overworked: with 
a subscript i, it indicates player i’s random tape; as a superscript, it indicates a round 
number. This should cause no confusion. Recall that, if r; (for example) is an infinite 
string, then r,; is its 7 bit. Finally, the symbols {#,},*,e,m}, which appear here and 
elsewhere, are all just formal punctuation symbols. 

Fix the notation 


rp rp orp rp 
Cr? = (8;?, 7°, mF") 


for player configurations, and the notation 


ure M(sf®) if r > 0 and n(s{~") = round-done 
~. A otherwise 

gi sa m;(sf°) ifr > 0 and n(s-P”) = round-done 
a A otherwise 


for broadcast messages and messages sent out along private channels. (Intuitively, the 
former is what processor i “tries” to broadcast at the end of round r, and the latter is what 
processor 7 “tries” to send to j at the end of round r.) Let the common input, c, be the 
“{”-terminated prefix of sf°. Then the players’ configurations progress as follows: 


(P(e, 87°), 77°, 17°) if n(s;°) = compute and r > 0 
Gre) (37? *ri?, Tig Tig °°+, ™%|?) if (37?) = flip-coin and r > 0 
Gy otherwise 
Cy = Cy? ifipe Ns.t.r=0 or 7(8;°) € {round-done, protocol-done} 
(sf? *Mi*---+Mramti,*---«m";, if n(st°) = round-done and 
c(rtne _ ta) r>0 
cre otherwise 


If any configuration fails to be defined by the recurrences above, then the protocol is said 
to have diverged (on this execution). 


NOMENCLATURE. As mentioned, the first superscript indexes the round while the second 
superscript indexes the micro-round. The string CT° is called the configuration of party i at 
the beginning of round r, while C]™ is the configuration of party i at the end of roundr. The 
configuration C?° = CP is the initial configuration of party i. If the round r, micro-round p 
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configuration of party i is C/? = (s;?,rj’,7;°), then we refer to s;? as the computational 


state of player i at this point in time. The string M? is the message broadcasted by 7 in 
round r, and the string mj, is the message sent from 1 to j in round r. 


EXECUTING PROTOCOLS. In the absence of an adversary, an ezecution of an n-party pro- 
tocol P with common input ¢ = 1'#1"°#1°#1'#1"#C, private inputs 21,...,2, € D‘, 
histories 7,...,%, € U™, and coin sequences r,,...,T, € L” is the sequence of config- 
urations {C7} generated by P when the initial configuration of party i is taken to be 
CP° = (eta; ti, r;, 7). The set of executions of P with common input c, private inputs 7, 
histories 7, and all possible coin sequences 7,,...,7, € DS” enjoys a probability measure by 
endowing each execution with the measure induced by taking each bit of each r; to be se- 
lected uniformly and independently. In the absence of an adversary, executing a protocol P 
with common input c and private inputs 7, means sampling according to this distribution. 

The values specified on the common input, c, in an execution of an n-party protocol are 
called the security parameter, k, the number of players, n, the input length, , the output 
length, 1, the history length, m, and function description, C. Any of these values may take 
a subscript c to emphasize their being specified on the common input c. Since we will be 
interested in secure computation of functions, C, will specify—-somehow—a vector-valued 
or string-valued finite function, C, : (U%)"« — (Zle)"", or C, : (D%&)"= 4 De, 


MESSAGE DELIVERY. The string M/ is the message that processor 7 broadcasts at the end 
of round r, or A if processor 7 does not broadcast a message in round r. The string mj; is 
the messages that processor 7 sends to processor j at the end of round r, or A if processor 2 
does not send a message to processor j in round r. The empty message is delivered to each 


processor in round 1, since no activity occurred in round 0 (see below). 


Discussion. As mentioned, the history of a processor is thought of as information which 
a processor may possess which is not relevant to the task at hand, but which is nonetheless 
part of the processor’s configuration; for example, it might be the saved state before a 
subroutine call, and the currently executing protocol is really just a subroutine. To ensure 
that a processor does not “use” information it should not use, we do not include the history 
in a processor’s computational state. But, as we will see, it is there in the sense that 
when a processor is corrupted, its history is made available to the adversary. We note that 
we could, alternatively, have said that some properly-marked portion of each processor’s 
computational state is not allowed to be “used” by the protocol P. Saying this formally is 
more awkward than the approach taken. 

We have established the convention that a protocol begins with the players executing a 
“dummy” round, round 0; during this round, “nothing happens.” The presence of the void 
round facilitates bringing the adversary into the model of computation in a manner which 
allows for clean protocol composition. This will not, however, be a concern for us here. 
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2.3.3 Adversaries (Informal Treatment) 


MODELING ERRORS. So far we have described how a fault-less network operates. We now 
consider the possibility for some players becoming “bad” in an execution of a protocol— 
that is, of deviating from their prescribed instructions. In fact the goal of this chapter is to 
properly define those protocols that can “withstand” the action of some bad players. 

How powerful should we let these bad players be? In some scenarios the only natural way 
for a processor to deviate from a protocol is by ceasing all communications, such as in the 
case of a computer “crash.” Alternatively, processors may start sending messages “at ran- 
dom,” corresponding—for example—to having some short-circuited register. If people are 
behind their processors, it is safer to consider more “malicious” deviations. This possibility, 
clearly subsuming the previous ones, is the one we focus on. Our goal is in fact reaching 
the strongest, natural notion of security, so that a protocol satisfying our definitions may 
be safely and easily used in any natural context. We thus allow bad players to deviate from 
their prescribed instructions in any way—the only constraint we consider is that even bad 
processors may (perhaps) be computationally bounded, and there may be a limit on the 
number of bad players possible. We also allow bad players to secretly cooperate with each 
other. Actually, to guarantee their “perfect cooperation,” we envisage a single agent, the 
adversary, that during an execution of a protocol, may corrupt and control players. 

Let us now address an equally important question: when can the adversary corrupt 
players? One possibility is to consider a static adversary, one who can choose and corrupt 
a subset of the players only at the start of a protocol. Since any real adversary may 
be expected to make an effort to corrupt those players whose corruption would be most 
beneficial to her for the current execution, a better possibility is to consider a dynamic 
adversary, one capable of corrupting players at arbitrary points during the execution of a 
protocol, based on the information acquired from previous corruptions. This appears to 
capture the worst natural model of malicious behavior which one might hope to defeat in 
our scenario.® Such an adversary is provably more powerful than a static one (see [MR91]), 
and security with respect to a dynamic adversary is both harder to achieve and harder to 
properly define. 

If an adversary were allowed to corrupt all players, then nothing could be said about 
the behavior of the network. Thus the number of corruptible players will appear in our 
definition of security. 

We now refine these ideas, until we are ready to specify a “mathematical” description 
of an adversary, and how a protocol runs in the presence of such an agent. 


°For the Byzantine agreement problem [PSL80]—the problem perhaps most responsible for clarifying 
notions of adversarial behavior—even stronger adversaries can be postulated and defeated, including an 
adversary capable of “seeing” the internal states of all players, but capable of gaining control of the output 
of only a certain fraction of them. 
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Adversary’s round w 
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Figure 2.1: An execution of a protocol with the adversary. The player’s 0“ round is a round 


on which there is not activity—-so, effectively, the adversary begins and ends the execution 
of a protocol. 


ADVERSARIES INTERACTING WITH NETWORKS, Think of an adversary A as an abstract 
machine interacting with the participants of a network in a prescribed way. This way entails 
the players and the adversary alternating periods of activity, as suggested by Figure 2.1. 

In the beginning, the adversary and all the players in the network are quiescent. The 
adversary and players will take turns being active. In the beginning, all of the players are 
good, and so they remain unless the adversary corrupts them. Initially, all the information 
the adversary has on which to base these corruptions is the same common input which the 
players share. (If the players are entitled to this information without doing any work, so is 
the adversary!) 

At the start of every round, the adversary is quiescent. Once all of the still good players 
have finished their activities for this round, having well-defined out-going private messages 
and broadcast messages, the players go to sleep and adversary A is awakened and receives all 
broadcast messages just computed, together with all of the messages the players composed 
for already-corrupted processors. The adversary may then choose to corrupt some new 
processor 2. When she does so, within the same round, she learns all of 7’s internal state 
(his computational state, history, and initial private input), all of the messages which were 
just sent out by processor i (as a consequence), and all messages which were just sent to 
processor 2. 

After this, still within the same round, A can corrupt, one at a time and exactly as 
before, additional players, until she does not want to corrupt any more of them. At this 
point, the adversary composes all outgoing messages from the bad players to the good, 
and it is these messages (together with the messages sent by good players) which will be 
delivered to the players in the next round. 

This process continues until all of the processors have either been corrupted or have 
halted. Then the adversary is given one last period of activity. After this, the protocol is 
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said to have terminated. 
To formalize what we have just described, we will say that the execution of a protocol in 
the presence of an adversary follows the sequence of “macro-rounds” shown in Figure 2.1. 


” 


Within each macro-round, there may be many “micro-rounds,” in which the players per- 
form their local computations, or the adversary computes and corrupts various players, in 
sequence. We choose to think of the players as having a 0*-round in which no activity 


occurs; after that void round, it is the adversary’s turn to be active. 


THE ADVERSARY’S ADVICE. To obtain a robust notion of security, we demand that our 
protocols remain secure even if there is some information ag known to the adversary in 
advance of the protocol’s execution. Oren has pointed out the importance of providing such 
advice in the context of zero-knowledge proof systems [Or87]. The adversary advice might, 
for example, consist of information which the adversary has somehow come to acquire about 
the input vector Z—perhaps from previous executions of other protocols. Or, it might be 
information that depends on the security parameter k, which, perhaps, the adversary worked 
for years to come up with in a “preprocessing stage” of her attack on the protocol. The 
advice will be doled out in a manner like the coin flips are: when the adversary asks for the 
next advice bit, it is given to her and vanishes from the infinite string of advice remaining. 


WHY THE NONUNIFORMITY? Adversaries like the one we have described—who may possess 
some fixed information before the protocol begins, information, possibly hard to compute, 
tailored to the choice of security parameter or, in our case, the private inputs and proces- 
sor histories, as well—such adversaries are called called nonuniform adversaries (because, 
traditionally, such adversaries have been modeled by (possibly nonuniform) polynomial-size 
circuit families). Nonuniform adversaries have several advantages over their uniform coun- 
terparts, advantages which we now enumerate. Most importantly, since a cryptosystem is 
generally run for a particular choice of security parameter, one would be unhappy with a 
protocol which was only secure against uniform adversaries: a sufficiently committed at- 
tacker would mount an attack that would break the cryptosystem itself, a much worse break 
than just breaking a particular usage of the cryptosystem. Secondly, proofs are frequently 
simpler or more natural in the nonuniform model. Third, the main theorem of this thesis 
talks about how an arbitrary circuit can be used to specify a protocol for securely evaluating 
it; thus there is already nonuniformity present in the families of circuits which might be 


evaluated. 


2.3.4 Adversaries (Formal Treatment) 


ADVERSARIES FOR n-PARTY PROTOCOLS. Formally, an adversary will not be very different 
from the other participants of the collaborative computation; but she has additional abilities 
which allow her to make life difficult for the players. Defining how a protocol runs in the 
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presence of an adversary will be a matter of properly modifying the players’ and adversary’s 
computational state as she “interacts” with the protocol. 


Definition 2.3.2 An adversary for an n-party protocol is a function 


As. Se ON ee SN 
~ ~- “~ 
common current new 
Input state state 


An adversary interaction function is any of the following polynomial-time functions: 
1. a next-action function # : L* — {compute, flip-coin, get-advice, corrupt,,...,corrupt,,, 
round-done}, 
2. a broadcast messages function M : D* x [1l..n] — E*, and 
3. a private messages function, m: O* x [1..n] x [l..n] + &*. 


An adversary configuration is an element of 


Be, OR eo atl se 
SH SH SH Q_— SY 
adversary’s coins advice corrupted traffic 
state remaining remaining players 


Notation. In place of M(s4,i) and mn(s4,i,j) we will write M;(s4) and m;;(Sa), Tespec- 
tively. 


Discussion. We do not explicitly specify the interaction functions since the particular 
conventions selected for them is irrelevant. All that is important is that each function 
specifies its range value in a natural and simple manner from its domain value, as with the 
interaction functions associated to the players of a network. 

As with a protocol, the first component in A’s domain is the common input. Though 
this could be considered as an unnecessary component—it could be encoded in the second 
component, the adversary’s current state-—-we make a separate argument of it to facilitate 
specifying the computational complexity of an adversary. 

The function # describes the action an adversary wishes to perform: does she do some 
computation, flip a coin, corrupt some processor 7, or complete her activities for this round? 
Note that while a player may terminate, we choose to say that an adversary does not; we 
will select a formalization in which the adversary effectively terminates after all processors 
have done so. 

The string M;(s4) denotes the message that the adversary will broadcast for player i, 
if 7 has been corrupted. The string 7,;(s4) denotes the message that the adversary sends 
to processor j on behalf of processor i, if 7 has been corrupted. 

Note that, while a protocol must at least be computable, no similar assumption is made 
of an adversary; an adversary which is, say, an arbitrary function, with no finite description, 
is a perfectly good adversary. However, possible restrictions on the power of an adversary 
will be defined in Section 2.3.7. 
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The adversary configuration captures that information about the adversary’s computa- 
tion which needs to be remembered and updated across the application of A. The adver- 
sary’s computational state, the coins which she has not yet used, and the advice which she 
has not yet read are all components of the adversary’s configuration. Also included are the 
set of processors which are currently corrupted; this set grows with each corruption, and 
never shrinks. The final component of the adversary configuration is an encoding of the 
traffic of exchanges between the adversary and the players with whom she speaks. This 
quantity will prove sufficiently important to warrant explicitly specifying how it evolves as 
the adversary interacts with the players. 


2.3.5 Executing Protocols in the Presence of an Adversary 


We now describe how an n-party protocol P executes in the presence of an adversary A. 
After specifying the behavior formally, we will describe what it means in English. 


CONFIGURATION SEQUENCES. Let A be an adversary for attacking an n-party protocol, 
and let P be such a protocol. We describe how, from any n initial player configurations, 
(CP°,...,C0°), and any initial adversary configuration, C4° = (s4,74,@a,Ka,Ta), proto- 
col P and adversary A generate a sequences of player configurations, {Cj*: i € [l..n],r € 
N, p € [0..00]}, and a sequence of adversary configurations, {C7,’:r € N,p € [0..co]}. 


Fix the notation 


rp rp rp rp 
Cr? = (8p ares my" ),. and 
rp rp orp orp rp rp 
CO" = (Sh 9. Pas Gas Bas TH), 


and let the common input c and the private input # be given by ctz;}i = s?°. Once again, 
the symbols {#,#,*,e,m} are just formal punctuation symbols. The players’ configurations 
progress as before, 


(Pless)s te yt) if n(s;°) = compute and r > 0 
CGP e> (s7?erif?, rifrig +++, 7°) if n(s7’) = flip-coin and r > 0 
C7? otherwise 
Cy? = Cy? iff peNs.t.r=0 or 7(s;°) € {round-done, protocol-done} 
(sf MT & +++ Mo emi *++-4m";, if n(s?°) = round-done and 
Cote 2 Gee) r>0 


cr otherwise 
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while the adversary’s sequence of configurations progresses as follows: 


(Ale, 82), Ts an, Kay Ta’) if #(s'¢) = compute 


rp rp orp “por rp\ _ ‘ 
(Sy Ty Taal as ots ay, Kay Ta’) if (87) = flip-coin 


rp rp rp rp . ~ rp aay bd 
(sya, Tas yas, KA, Ta’) if (si) = get-advice 
(sip esl kTT™ kOe HM KO FIT, if (3%) = corrupt; 
r(p+1 
cre) = rf, af, wf U {i}, and r > 0 
TR aca ch roo a — 5 
Ti etest kT OE MEX + KM ;) 
(siPest? aml *2,, if 7(s7f) = corrupt; 
rp = 
es and r= 0 
Ty eiest® #17 x; ) 
CY otherwise 
(Si tay Gag ha ifipeNstr>0 
r Peat ae i mt ohP\ — 
Tee Mies eM eM e+ eM +++ and (87?) = round-done 
CS = seek es kT mw) 
(S00 fo Ray Ka Tae) otherwise 
(sta Mit e-- eM tlamit lee. emit amt la. amet}, 
rp - ‘ 
rye, an, KR, ifr>0 
1)0 y ¥ as = = as 
cg = Tyee M Tt ee aM tlemitle) amitle..samttle.. mrt!) 
CPare, eee ifr =0 
where 
. . 1 
M(st@) ifr >Oandi¢ Kt and n(s\"~?™) ¥ protocol-done 
Mr = Mi(s°) ifr >O andi € KY 
A otherwise 
ore) ‘ ‘i roo (r—1)oo 
m(sf°) ifr >Oandi ¢ Ki and 7(s; ) # protocol-done 
r anes ~ roo < - r 
mi, = m(s°) ifr > 0 andi € Ki? 


A otherwise 
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we { M(si@) ifr>O andi ¢ Ae and n(sf- 0%) # protocol-done 
a A otherwise 
m;(si°) ifr>Oandi¢ KEY and j EKG") and 
m, = n(s°— °°) # protocol-done 
A otherwise 
mw = M,(s"°°) ifr >O andi € K'° 
; A otherwise 
~ mi(s7°) ifr >O andi € KY? and 7 ¢ Ky? 
™m.. — 
is A otherwise 


If any configuration fails to be defined by the recurrences above, then the execution with 
the specified initial configuration is said to have diverged. 


NOMENCLATURE. The tuple CY° is called the configuration of party i at the beginning of 
round r, while C{™ is the configuration of party t at the end of round r. The configuration 
CP° = Ce is the initial configuration of the party i. The tuple Cy is called the configuration 
of the adversary at the beginning of round r, while CX is the configuration of the adversary 
at the end of round r. The configuration C& = C?© is the initial configuration of the 
adversary. 

If the round r, micro-round p configuration of party i is Cy? = (s;°,7;°,7;°), then we 
refer to s;° as the computational state of player i at this point in time. The string M/ is 
the message broadcasted by 7 in round r, and the string mj, is the message sent from t to j 
in round r. 

If n(s'°) = protocol-done, then Cf is called the final configuration of party i. The 
value C'{° is called the adversary configuration at the end of round r. 

Player j is corrupted in round r if #(s'/) = corrupt; for some p. Processor i terminates 


at round r if ris the first round for which 7(s'°) = protocol-done. 


EXECUTING PROTOCOLS. In the presence of an adversary A, an execution of an n-party 
protocol P with common input c = 1*#1°#1°#1'#1"#C, private inputs 21,...,2n € ©, 
histories ™,...,% € &™, player coin sequences 71,...,T, € L”’, adversary coin sequence 
ra € &”, adversary advice ag € %”, and initial corruptions Ka, is the collection of con- 
figurations {C;’,C%’} generated by P and A when the initial configuration of party i 
is taken to be C?° = (ctaz;ti, r;, 7;), and the initial configuration of A is taken to be 
(exKa, Ta, Ga, Ka, C¥KA). The set of executions of P with common input c, private inputs 
#, histories #, adversary advice ay, initial corruptions «4, and all possible coin sequences 7 
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and r4 becomes a probability space by endowing each execution with the measure induced 
by taking each bit of r4 and each bit of each r; to be selected uniformly and independently. 
In the presence of an adversary, executing a protocol P with common input c, private inputs 
Z, histories 7, and adversary advice a4 means sampling from this probability space. 


MESSAGE DELIVERY. We explain the meaning of the various m&M’s. The string M7 is 
the message an uncorrupted processor i “tries” to broadcast to the network in its round r. 
Due the adversary’s activities, some other message Mf may actually be broadcast to the 
network on behalf of player 7. The string mj, is the message an adversary receives from an 
uncorrupted processor i, intended for (corrupted) processor j. The string mj, is the message 
that a (good) player 7 receives on behalf of player 7, the source of this message depending 
on whether 7 is corrupted or not. The string M/ is the message the adversary broadcasts in 
round r on behalf of the corrupted processor 7; the string mi, is the message the adversary 
sends in round r to the uncorrupted processor j on behalf of corrupted processor 7. 


THE ADVERSARY’S INTERACTION WITH THE NETWORK. When the adversary corrupts a 
processor, she learns the current computational state of that processor, and the history as- 
sociated to that processor. Additionally, she learns that processor’s private input. As long 
as there are messages which were delivered to the corrupted processor in this round (i.e., 
as long as it is not round 0), the adversary is given those messages which did not originate 
from the adversary herself. When the adversary terminates her activities for some round, 
the messages she composes on behalf of the corrupted processors are then delivered. When 
the processors terminate their activities, the messages which they compose and which the 
adversary can see (broadcast messages or messages sent to corrupted processors along pri- 
vate channels) are delivered to the adversary. So that the formalism matches the intuition, 
we demand that an adversary corrupts a processor at most once: if (s'¢) = corrupt;, then 


A(sy’) A corrupt, for all (r’, p') < (7,p). 


TRAFFIC. The “traffic” of exchanges between the adversary and the uncorrupted processors 
consists of everything the adversary “gets” from the currently good players—the messages 
they broadcast, the messages they send to corrupted players, and the information the ad- 
versary learns when one of these good players is corrupted—together with the information 
that the adversary “gives” to the currently good players—the messages the adversary broad- 
casts on behalf of corrupted players, and the messages the adversary sends out along private 
channels to uncorrupted players on behalf of corrupted players. As we have formalized it, 
the traffic also includes (tacked onto the beginning) the common input and a description of 
the initially corrupted processors. 

In words, each time a processor 7 is corrupted, the information learned from that proces- 
sor which augments the adversary’s state is tacked onto the transcript of traffic, preceded 
by an indication of which processor was corrupted; each time the adversary completes her 
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round-r activities, the messages she has composed on behalf of corrupted players is ap- 
pended to the transcript of traffic, terminated by a special marker; and, finally, each time 
the adversary is awakened as a result of the player’s completing a round, those messages sent 
by good players which are received by the adversary are properly delineated and appended 
to the transcript of traffic. 

If r4 specifies traffic, then corrupted(r,) denotes the set of processors who are corrupted 
in this transcript—that is, the set of all 7 such that ete appears in r4*—and ¢(r,4) denotes 
the input length in this traffic—that is, the value @ such that c = 1'#1"#1°# --- is a prefix 
of T,4. 


OUTPUT AND TERMINATION. A protocol is said to terminate in round r if r is the first 
round at the end of which every uncorrupted processor has terminated. We demand the 
following of any protocol P: for any adversary A with which P may interact, when P runs 
with A, P terminates with probability 1. 

Player i’s output in an r-round execution of a protocol P is the image y; = o(s7~) 
under o of that players final computational state, if the player is uncorrupted at the end of 
round r, and the distinguished value corrupted otherwise. The players’ output is the tagged 
vector consisting of each player’s output different from corrupted. 


ADVERSARY’S VIEW. In an execution e of an adversary A with a network, the view of A 
in this execution is “everything the adversary sees” before termination: that is, the triple 
(ta,17,,@,) consisting of the traffic, the adversary’s coins actually consumed (a prefix r’, 
of the infinite string 74), and the adversary’s advice which is consumed (a prefix a’, of the 
infinite string a4). A random bit is consumed when 7 becomes flip-coin; an advice bit is 


consumed when 7 becomes get-advice. 


2.3.6 Dealing with Arbitrary Numbers of Players 


GENERAL PROTOCOLS. To properly talk about general multiparty protocols we must relax 
the requirement that a protocol is tailored for one particular number of players. (It is 
discussed in [MR91] why imagining n fixed is too restrictive.) Thus we treat a protocol 
P as a family of n-party protocols P = {P,}. However, recall that we demanded that a 
protocol be “describable” by a Turing machine (that is, we demanded a protocol be Turing- 
computable). In passing to more general protocols, we would like not to lose this property. 
In fact, any “reasonable” protocol should have a description that is efficiently computable 
knowing the number of players involved. 


Definition 2.3.3 A protocol P is a polynomial-time computable function that maps a 
number 1” to a standard encoding of an n-party protocol P,. 


“If corruption is interrogation followed by murder, surrounding 7 with bullets is quite mnemonic! 
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We will usually suppress the subscript n when considering an n-party protocol P,, using P 
to denote either a general protocol or a particular n-party protocol that it specifies. 


GENERAL ADVERSARIES. Likewise, to talk about a protocol with arbitrary numbers of 
players under attack by an adversary, we must suitably relax our notion of an adversary. 


Definition 2.3.4 An adversary A is a function that maps a number 1” to an n-party ad- 
versary Ay. 


Again, we usually suppress the subscript m when considering an adversary for an n-party 
protocol, using A to denote either a general adversary or an adversary for a particular value 
of n. 


2.3.7 Complexity Measures 


ADVERSARIES WITH BOUNDED CHARISMA. If an adversary corrupts all the players, then 
nothing can be said about their behavior in her presence. We thus prefer less captivating 
adversaries. 


Definition 2.3.5 A t(n)-adversary for a protocol P is an adversary A for which |K7f°| < t(n) 
for any r-round execution of A, with the n-party protocol Py. 


For our purposes, we may imagine that the constraint above is strengthened to demand 
that the adversary always corrupts eractly t(n) players, rather than at most t(n) players. 
As long as t(n) is efficiently computable and the adversary “knows” when the protocol will 
terminate, the notions are equivalent. This will be the case for us. But in contexts like the 
Byzantine agreement protocol of Feldman and Micali [FM88a], these conditions are not met. 
Often, ¢(n) is a step-function associated to linear function of n, such as t(n) = [(n — 1)/2}]. 


LOCAL COMPUTATION COMPLEXITY. Let e = {Cj’,C%°} be an execution of an n-party 
protocol. The number of player micro-rounds for execution e is 


l{C7? : ie [1..n], r,p € N, n(s7?) ¢ {round-done, protocol-done}, and i ¢ K"7P°}|, 
while the number of adversary micro-rounds is 


l{Ch’: r,p EN, n(s?) # round-done, and the protocol has not terminated 
before round 7r}{. 
A protocol P = {P,,} is polynomial-time if there is a polynomial Q such that for any n, P, 
is Q(|c|)-time computable (where c is the common input); and for any execution e with any 
adversary A, the number of player micro-rounds is bounded above by Q(|el). 

An adversary A who interacts with a polynomial-time protocol P is polynomial-time if 
there is a polynomial Q such that the encoding of A, is computed by A in time bounded 
above by Q(n); and A, is computable in time at most Q(|c|); and, last of all, the number 
of adversary micro-rounds is bounded above by Q(|e|). 
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ROUND AND COMMUNICATION COMPLEXITY. The round complezity of a protocol P is least 
value r such that when protocol P is run in the presence of an adversary A it necessarily 


” if no such number exists. The 


terminates within r rounds. The round complexity is “oo 
round complexity is regarded as a a function of |e|. 

The communication complezity of a protocol P is the least value A such that when 
protocol P is run in the presence of an adversary A, the total number of bits sent out by 
uncorrupted processors is at most K. The total number of bits sent out by uncorrupted 
processors is 5°, ; 6(¢ ¢ Ka(sf~P°))\(|Mr| + >; 1m7,|), where 6 is 1 for a true predicate, 0 
for a false predicate. The communication complexity is “oo” if no such number exists. The 
communication complexity is regarded as a a function of |c|. 


2.4 Secure Function Evaluation 


With the language of Sections 2.2 and 2.3 in hand, we begin to phrase our definition of 
security. We begin by providing some intuition as to what correctly and privately computing 
a function should mean in the presence of an adversary as strong as the one we have defined. 


2.4.1 The Ideal Evaluation 


A secure protocol should mimic—as closely as possible—the computation of a function f by 
an ideal protocol for computing it. An ideal protocol for f can be considered as achieving 
security by adopting a model of computation which provides a trusted party for computing 
the function. The rest of the parties, though, are subject to corruption. We describe the 
ideal protocol somewhat more colorfully below. 

Imagine distributively computing f : (D6)" — (')” by playing the following game. 

Each player sits at a table, his private input string written underneath the lead plate in 
front of him. One by one, the adversary “corrupts” some of the players, removing a player’s 
lead plate and learning the information written beneath it. Then the adversary substitutes 
(fake) input strings 24, in front of each of these corrupted players, and she replaces the lead 
plates. Once the plates have all been replaced, the value of f;(a U 27), magically appears 
underneath the plate of each player 7. In this way, each player i has computed f evaluated 
at a vector of inputs which—though partially determined by the adversary—still, has been 
correctly evaluated at a point 27 Uay, where x was chosen independent of the good players 
private inputs. 

After the adversary learns the f;(27 Uz7)-values for the already-corrupted players 7, one 
by one, she may corrupt additional players 7. Removing their lead plates, the adversary 
learns their z;- and f;(2 U rz)-values. All together, she may corrupt a total of t players. 


TURNING THE IDEAL PROTOCOL INTO A DEFINITION. The formalization of security at- 


tempts to ensure that the computation of f by the protocol is “just like” the computation 
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of f by the ideal protocol which computes f. Unfortunately, it is not obvious what “just 
like” really means. We attempt to imitate the ideal computation in all essential ways. 

For example, in the ideal protocol, the adversary “knows” what values x4, she substitutes 
in under the plates of corrupted players, and she “knows” what her share of the output is 
as a result of these substitutions. If a protocol does not enjoy this property, might it still 
be secure in some significant sense? Absolutely. But our viewpoint is that all important 
aspects of the ideal protocol should be mimicked in a protocol we call secure—-and the 
adversary’s substitution on a given run of a value a (a value she is aware of) on behalf 
of the corrupted players would seem to be an important aspect of the ideal protocol. See 
Section 2.5 for some additional discussion. 


2.4.2 Ideal Evaluation Oracles 


To formalize our notion of security, we develop an abstraction for how an adversary can 
corrupt players and steal information in the ideal protocol for computing f. Though the 
following notion does not appear explicitly in our formalization of security, the language it 
offers in useful, and the informal description is helpful in understanding the formalism of 
Section 2.4.3. In Chapter 4, we will will speak in terms of oracles to make more under- 
standable the proof of that chapter. 

We imagine a special type of oracle, O,(#,7; f), whose behavior is dictated by the 
players’ inputs Z € (X*)", their histories # € (*)", the function f to be computed, and the 
bound t € [0..n] on the number of processors the adversary is allowed to corrupt. We now 
describe how this oracle behaves. 


The oracle accepts two types of queries: 


e A component query is an integer 7, 7 € [1..n]. It is answered by (;,7;) if t or fewer 
component queries have been made so far, and no output query has been made so far; 
it is answered by ((2;,7;), y;) if t or fewer component queries have been made so far, 
and the proper output query 2 previously made resulted in a response J = f(apUz7). 
Additional component queries are answered by A. 

e An output query is a tagged vector x. The query is valid if T consists precisely of the 
component queries made so far, and if this is the first output query. Asking a valid 
output query 27 results in the oracle computing 7 = f(z Uap), and answering yr. 
An output query which is not valid is answered by A. 


Let us emphasize that the oracle is willing to answer at most t component queries. If the 
oracle is asked an improper output query (that is, T is not the set of previous component 
queries), or if the oracle is asked more than one output query, it does not give the requested 
information. Note that we do allow component queries to follow the output query, so 
long as the total number of component queries is bounded by t. Also, component queries 
behave differently depending on whether or not the output query has been made: if the 
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output query has been made, then a component query returns (in addition to the requested 
component) the queried player’s “share” of the function value. 

Clearly what you (as a t-adversary) can learn when speaking to a ideal evaluation oracle 
exactly coincides with what you can learn in the ideal computation of f. Privacy is then 
easy to formalize using ideal evaluation oracles: roughly said, the ensemble of views you 
get as an adversary interacting with the protocol is indistinguishable from an ensemble of 
views you can generate without speaking to the network, but speaking to some algorithm 
equipped with ideal evaluation oracle, instead. 

Actually, we will define not only privacy but correctness, too, through the interaction 
of an algorithm with its ideal evaluation oracle. 

If O,(@, 7; f) is an oracle, we will sometimes omit the subscript t and the parenthesized 
arguments Z, 7 and f, and write simply O, instead. The response to a component query 
of i is then written simply as O(i), and the response to an output query of z> is written 
simply as O(27,). 

The description of an ideal evaluation oracles just given handles vector-valued functions. 
In fact we will be interested both in secure computations in which every player will get his 
own private output, and in secure computations in which all players will get a common—and 
thus public—output. 

For the purpose of computing string-valued functions, the definition of component 
queries can be simplified: a component query i returns 2; if there have been ¢ or fewer 
component queries so far; there is no need to return the value y; for queries made after the 
output query. 


2.4.3 Simulators 


We now introduce a key tool for achieving our definition of security: simulators. This notion 
was also central to the definition of zero-knowledge proofs, of which protocols for secure 
function evaluation are an extension. There are, however, several adjustments to be made, 
reflecting the several differences of context. 


2.4.3.1 Informal description 


SIMULATORS TALK TO ADVERSARIES. A simulator is an algorithm which interacts with an 
adversary with “mechanics” similar to the interaction between an adversary and a protocol, 
as suggested by Figure 2.2. We describe this mechanics below. Later we will concentrate 
on those simulators interacting with which is indistinguishable—to the adversary-—from 
interacting with a network. 

We point out that we are demanding more of our simulators than is customary to 
demand of simulators for zero-knowledge proofs [GMR85]. Our simulators are required to 


lay down a conversation with an adversary in a message-by-message manner, something 
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Figure 2.2: A simulator S$ creates a “virtual world” and allows the adversary A to act in 
this world, as though S' itself were a network running protocol P. 


which has never been demanded in simulation for zero-knowledge proofs. Crépeau [Cr90}] 
also explicitly demands this type of simulation, and it is discussed by Kilian as well [Ki89]. 
This restriction is central to achieving our notion of correctness, since it is through this 
mechanics of the adversary speaking to the simulator that a meaningful “committal” can be 
associated with the execution of an adversary with a network, not just with a simulator. We 
caution that this restriction is different from the “black-box” notion sometimes considered 
for zero-knowledge proofs. 


SIMULATORS OWN IDEAL EVALUATION ORACLES. It will be the simulator’s responsibility 
to send to the adversary messages which would “appear” to be from the network itself. 
To this end, a simulator is provided an ideal evaluation oracle. When and only when the 
adversary A with which simulator $ speaks corrupts a processor 7, simulator S makes a 
component query of 7. Once, and only once, the simulator makes an output query 27, 
where T is the set of processors currently corrupted by A. We will say that the simulator 
does this at some point just following the the completion of an adversary round, after the 
adversary’s outgoing messages have been composed and sent to the simulator. Presumably, 
the simulator’s output query was required to provide the next round of messages going to 
the adversary from the simulator on behalf of the uncorrupted players. 

A simulator is sometimes productively thought of as the “subconscious” of an adversary 
who is endowed with an ideal evaluation oracle, but who does not having benefit of a network 
with which to compute. Everything that a simulator gives to an adversary an adversary 


could give to herself—if only she had the oracle. 


DEPENDENCY OF S ON A. There are issues involved in deciding to what extent the simu- 
lator’s behavior may depend on the adversary A with which it interacts. At one extreme, 
the simulator might “see” the adversary’s current state, the advice string which A has been 
given, and the coins which A flips; and the simulator algorithm may depend in an arbitrary 


manner on the adversary’s algorithm itself. This is the least restrictive requirements for a 


47 


simulator, giving rise to the weakest notion of security. 

At the other extreme (and there are many in the middle), the simulator knows nothing 
of the adversary’s program, advice, coins, or internal state, and it must provide its messages 
without such benefit, based only on the traffic exchanged between itself and the adversary. 
This is the most restrictive requirement for a simulator, giving rise to the strongest notion 
of security. We adopt this notion here. Note that it is completely meaningful to have such 
a simulator interacting with an adversary who computes an arbitrary function. 


COMPUTING THE OUTPUT QUERY. How does the simulator compute its output query? 
Necessarily, it is a function of the simulator’s coins, its oracle responses, and the traffic of 
exchanges between itself and the adversary. But we wish to be less generous. Why? 

Key to achieving strong notions of reducibility and independence (see Section 2.5) is 
that the adversary should know the output query. But if we allow the simulator to compute 
its output query without any restrictions, then the adversary—not knowing the simulator’s 
coins—cannot possibly know this. One (particularly restrictive) way to demand that the 
adversary knows the output query (meaning that she could compute it, if she wanted to), 
is to demand that the simulator’s output query must be an efficiently computable function 
AT (for “adversary input”) of just the traffic of message exchanges. Though less restrictive 
notions are possible (and are in fact necessary to properly deal with secure computation 
in the broadcast model), the issue is always the same: how to ensure that the adversary 
knows what the output query is, in the sense that it can be calculated by the adversary in 
toughly the time allotted for the execution. 


ADVERSARY OUTPUT. In the ideal computation of a protocol, the adversary necessarily 
learns not only what she has sent off to the trusted server, but she also learns what the 
trusted server returns to her (that is, her share of the output). Through the AZ function we 
have mimicked the former; through the AO function (for “adversary output”) we imitate 
the later. Like the adversary input, the adversary output AO is an efficiently computable 
function of the traffic. In an r-round execution of a protocol, the adversary’s share of the 
common output is yr = AO(c,7,”), where T = corrupted(r{”) is the set of players who 
are corrupted when the protocol terminates. 


> STRONG SIMULATABILITY. We emphasize that the restriction that AZ and AQ be ef- 
ficiently computable functions on the traffic is a lot to demand. More general notions of 
simulatability are less restrictive on this point. The spirit of definitions which capture the 
sense in which the adversary is aware of her input and output is the same, but is not dealt 
with here. Refer to [MR91]. 
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2.4.3.2 Formal description 


DEFINITION OF A SIMULATOR. We define a simulator as a triple consisting of the simulator 
algorithm proper and two associated (total) functions on the traffic. These specify what 
the adversary has effectively sent to the trusted server and received from the trusted server. 


Definition 2.4.1 A simulator S = (S, AZ, AQ) is a polynomial-time computable function 


Oe Oe dite. Sy Ee et Ee 
~ “— “~ “~ 
common current simulator new 
input state coins a 


together with a polynomial-time computable adversary input function 


» oY yx HFK, alt-n]xz’ not-now 
AI at }, 
common traffic substituted 
input values 


and a polynomial-time computable adversary output function 


AO® SS OS, She 
Se SH — 
common final deserved 
input traffic output 


The function AZ has the property that for any traffic Tr, either AT(c,74°°) = not-now or 
else AT(c, 74°) € corrupted(r4~) x E74"). In the later case, AT(c, 8%) = not-now for all 
r<r. 
A simulator interaction function is either of the following polynomial-time computable func- 
tions: 

1. a next action function T : D* — {compute, protocol-done}, and 


2. a give-to-adversary function ® : %* = &*. 


A simulator configuration is an element of _&* x >” 
QeH Nang 


simulator’s simulator’s 
state coins 


Discussion. As before, the simulator interaction functions are fixed maps which determine 
their range points in a natural, easily encoded manner from their domain points. 

Recall that we chose to say that the adversary does not terminate; the protocol is said to 
terminate in the adversary round following the termination of all uncorrupted processors. 
Since there is no protocol running when an adversary interacts with a simulator, it is a 
simulator’s responsibility to effectively indicate when the protocol should be regarded as 
being over. It does this with its next action function, ®. 

The simulator’s other interaction function is used to read off, from the simulator’s com- 


putational state, what it provides to the adversary with whom it is interacting. 
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RUNNING AN ADVERSARY WITH A SIMULATOR. When having an adversary interact with a 
protocol, the adversary went through the following sequence of configurations: 


(Ate) Te at, Ry Te) if 7(s7f) = compute 


rp. orp rp orp rp rp rp ‘foe OTP\ gts : 
(Se i Pal ag hy Oh as Ea) if Hs") = flip-coin 


rp. orp rp rp orp wp rp tf oer OP P\ __ - 
(spa, Ty Wynd gees, Kay TH if Hi sf) = get-advice 
(s7P xSP H APO KE AMY e+ KTM |, if #(s°°) = corrupt, 
Cer) zt ry, af, KP U {i}, and r > 0 


Ta ete] st° xr! 


rp roo roo if Hf erP) — 
(87f # shan Ox; |, if #(s"f) = corrupt; 
re, ma, Kf U {a} and r= 0 


Ly Pry roo roo 
Tip ete] STP eTT™ x2; |) 


CP otherwise 
(So Tas Oa eke, ifipeNst.r>0 
rp lager Area? ~ ae or P\ 
Ta *Mix--- Memmi *-- #1 * and #(s’f) = round-done 
Ce = see ee kM MD) 
CVPR SC eR eee) otherwise 


eo 


roo roo roo roo TOO 1 — 
(See te ee ifr=0 


The boxed quantities indicate the points at which the the adversary has obtained informa- 
tion from the players in the network, and where this information appears in the updated 
traffic. The idea for defining the behavior of a simulator interacting with an adversary is 
to have the simulator—rather than the protocol—provide the boxed quantities, above. 

To run an adversary A having associated adversary input function AZ with a simula- 
tor S$, common input c = 1*#:1"#1°#1'#1"#C, (where C, specifies a function f, : (h°)" + 


(=')"), adversary coins r4, adversary advice a4, simulator coins rs, and oracle O,(Z, #; f), 
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where % € (X‘)" and # € (&™)", the boxed quantities above are replaced by that informa- 
tion which the simulator returns—as specified by ®—and the simulator’s state is allowed 
to progress in time in a manner analogous to a protocol’s progress in time. 

To describe this, fix the notation that 


Tp rp rp 
Cs _ (85 » Ts i 
and let the adversary configurations progress according to 
rp rp orp Ure rp eC = Op) __ 
(Alege lee ie ay Ra te if #(s7f) = compute 


rp, orp rp rp rp rp rp 'f 7 OTp\ __ git : 
(se *r a, MyoTas +, Gay Kay Th if (8°?) = flip-coin 


(s'frane, rf, a fangy---, KP, Th?) if (5%?) = get-advice 
1 si 
(softer @(sG°*Y) | if #(s°?) = corrupt, 
CE = Pastas fe Ut, and r >0 


Ty vie] (85°) | 
(sf 6(85°*) if #(s°?) = corrupt, 


Fo Ma ea WAT and r=0 


ry vie] O(50°")} 


Cy otherwise 
(84572, Ga, ®£; ifipeNst.r>0 
rp yr Treat ~ ~ rp\ __ 
Ta *Mi*--- Mrxiniy# + mie and (s'°) = round-done 
roo at ay? 
Ce = kT ee KTM mw) 
Ch otherwise 
roo (r+1)0 
(sie O(sg7) I, 
Pes Bae ifr >0 


(r41)0 7 
Ca = TOC xk (89+) ) 


(Sq %) Fa pa vRa sta) HSH 0 
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while the simulator’s configurations progress according to 


(S(c, si?*O(i), rs), Ts) if n(s%?) = corrupt, 
Cate = 


Ce’ otherwise 


CSe = Cy ifipe Ns.t. #(s%f) € {round-done, protocol-done} 


CLTD? = (Sc, 8%°+O(AL(c,72”)), rs), Ts) 


where 


(xj, 7) if Vr <r, AZ(c, T°) = 9 


O(z) = ((t:, 7), Yi) iflr<rs.t. 
ty = AT (c, ri) # not-now 


and f= f.(x> U rp) 
O(z7) = yr where J = f.(2> U 2#) 


and O(not-now) = A. 

In defining simulators for string valued computation, the definition of component queries 
is simplified to O(2) = (x;,7;) but the rest of the definition of a simulator interacting with 
an adversary is unchanged. 


TERMINATION. A simulator is said to terminate in round r if r is the first round for which 
Y(s%’) = protocol-done. The adversary with which the simulator interacts is then said to 
terminate at the end of its round r. 


ADVERSARY’S VIEW. In an execution e of an adversary A with a simulator, the view 
of A in this execution is “everything the adversary sees” before termination: that is, the 
triple (74, 7‘,, @/,) consisting of the traffic, the adversary’s coins actually consumed, and the 
adversary’s advice which is consumed. 


REQUIREMENTS ON AZ AND AO. For S = (S,AZ,AO) to be a simulator establishing the 
security of some protocol P, we demand that in any r-round execution of an adversary A 
with P, that there is exactly one value r’ < r such that AZ(r{°) = 25 # not-now. 
Additionally, AO(r4°) € corrupted(rA°) x Eta”), 

That is, the adversary input assumes a well-defined vector of “substituted inputs” z> 
at some point in the execution, and the adversary output, evaluated at the final traffic, 
specifies a meaningful output on behalf of the corrupted processors. 
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2.4.4 Ensembles for Secure Function Evaluation 


THE PARAMETER SET L(f). A vector-valued function family f is a way to interpret each 
common input c as a map f, : (D‘)"= — (Z/e)"«; a string-valued function family f is a 
way to interpret each common input c as a map f, : (H“)"* — Lie. The description of f, 
appears on the common input following the usual quantities. Thus to each function family 
f = {f-} we associate the k-indexed family of languages L(f) = {Lz(f)} given by 


L,.(f) = (iy {(Z,7,a4,c): EE (ZU‘)", FE (U™)", ag € DY, and 
n>3, k,6,l,m>0 


c= 1F#1°#1'#1'#1"#C,, where C, specifies a 
function f, from the function family f} 


of all possible inputs, histories, adversary advice strings, and common inputs, in any 
“proper” initial configuration of the network. 

Restricting our attention to proper initial configurations (with the void set of initially 
corrupted processors), the initial configuration of the players and the adversary are uniquely 
identified by a vector (Z, #,a4,c, Fra). This is a point in L;(k) together with coins 7 for 
the players and r, for the adversary. 

Just as (£,7,a4,c, F,r4) specifies the initial configuration of the players and the adver- 
sary, a point (#,7,a@4,c, rs,ra) uniquely specifies the initial configurations of the adversary 
and a simulator S, This is a point in L,(k) together with simulator coins, rs, and adversary 
coins, r,4. 


THE ADVERSARY’S VIEW. Consider an adversary, A, attacking a protocol, P. Let f = {f.} 
be a function family. With a proper initial configuration specified by (Z,#,a,4,c, 7,7), 
there is an associated view which will be held by the adversary at termination (if the 
protocol terminates). Omitting mention of 7 and ra, there is an associated distribution 
on adversary views induced by the taking each bit in 7 and ry, to be selected uniformly at 
random. We let 

A-VIEW{ (2, 7, a4, ) 


denote this distribution of adversary views. Read this as the view which A gets when 
speaking to the network running protocol P. When Z, 7, a4 and ¢ are not regarded as 
fixed, but are allowed to vary in L;(f), then A-VIEW{(@,7,a4,c) becomes an ensemble 
€A-VIEW;, (@, #,a4,c) indexed by k and parameterized by L(f). Sometimes we simplify 
the notation by writing €P,(#,7#,a4,c) or €P;, in place of €A-VIEW/ (Z, #,aa,°). 


THE SIMULATED VIEW. Consider an adversary, A, interacting with a simulator, 5. Let f = 
{f.} be a function family. With a proper initial configuration specified by (Z,7,a,,¢, Ts,Ta), 
there is an associated view which will be held by the adversary at termination (if the protocol 
terminates) when A talks to simulator S, where $ has an ideal evaluation oracle O(2, 7; f.). 
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Omitting mention of rs and ry, there is an associated distribution on adversary views 


induced by the taking each bit in rg and r, to be selected uniformly at random. We let 
A-VIEW 3 (2, #,a4,¢) 


denote this distribution of adversary views. Read this as the view which A gets when 
speaking to the simulator S. When 2, 7, a4 and ¢ are not regarded as fixed, but are allowed 
to vary in L,(f), then A-VIEW?(£,#,a4,¢c) becomes an ensemble £ A-VIEW; (4, 7, aa, ¢) 
indexed by k and parameterized by L(f). Sometimes we simplify the notation for this 
ensemble by writing €S0(#, #,a4,c) or ES in place of EA-VIEW; (Z, 7, a4,¢). 


NETWORK INPUT. Consider an adversary, A, attacking a protocol, P. Let f = {f.} be 
a function family, and let S be a simulator with adversary input function AZ. With a 
proper initial configuration specified by (Z,7,a,4,c, 7,ra), there is (as long as the protocol 
terminates) a well defined tagged vector x which is the 2-value obtained by evaluating 
the adversary input function AZ on traffic values 7{~ for r = 0,1,..., until a value different 
from not-now is obtained. Define 


NI(Z,#,04,¢, 77a) = vp U az. 


This is the n-vector of good players’ private inputs “shuffled in” with the values entered 
into the computation by the adversary, as indicated by AZ. It is called the network input 
function, and, intuitively, it specifies, on a particular run, what the network has committed 
to on this run. 


NETWORK OUTPUT. Consider an adversary, A, attacking a protocol, P. Let f = {f,} be 
a function family, and let S be a simulator with adversary output function AO. With a 
proper initial configuration specified by (%,7,a,4,c, 7,r,), there is (as long as the protocol 
terminates) a well defined tagged vector y; which is the result of applying the AO-function 
to the traffic 74° which has occurred when the adversary terminates. Define 


NO(E, 7, a4, ¢, TT) = Yr U UF 


where y# is the vector of outputs of good players. The vector above consists of good players’ 
outputs “shuffled in” with the output values for the adversary specified by the function AO. 
The function NO is called the network output, and specifies, intuitively, what the good 
players did compute as output values, and what the adversary could compute as output 
values on behalf of the corrupted players. 
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2.4.5 The Definition of Secure Function Evaluation 


We are now ready to define what it means for a protocol P to securely evaluate a function 


family f = {fc}. 


COMPUTATIONAL SECURITY. We first define what it means for a protocol for function 
evaluation to be secure with respect to a computationally bounded adversary. 


Definition 2.4.2 Protocol P t-securely computes f = {f.} if there is a simulator S = 
(S,AZ,AQ) such that for any polynomial-time t-adversary A, 


e (Privacy) €A-VIEW} (2,7 #,Qa,C) cr ) &A- VIEW; (@, 7,44, ¢). 


e (Correctness) For some negligible Sanction e(k), for all (Z,7,a4,c) € L,(f), 


Proby,, [VO(Z, #,a4,¢, *, ra) # f-(NIZ(Z,#,a4,c, 7, 7ra))] < e(k). 


Definition 2.4.2 can be explained as follows. When the adversary talks to the network, 
what she is learning is that which she can computationally closely approximate given an 
ideal evaluation oracle. How the adversary would compute the output query to this oracle 
defines what she commits to on a run of the protocol with the simulator. According to this 
function, when the adversary talks to the network, what she does is to effectively commit 
to a value x7. By the time the adversary terminates, she is in possession of a value yr, 
T 2T. During this run, almost certainly the good players computed yr = fr{x> U ap) 
and the adversary has learned yr = fr(x> U cp). 


STATISTICAL AND PERFECT SECURITY. We now define what it means for a protocol for 
function evaluation to be secure with respect to an adversary with unlimited computational 
power. The only change that is made is to require statistical closeness for privacy. The 
following notion is also called information-theoretic security.® 


Definition 2.4.3 Protocol P statistically t-securely computes f = {f.} if there is a simulator 
S = (S,AT,AQO) such that for any t-adversary A, 


e (Privacy) €A-VIEW; (Z,7,a4,c) xy EA -VIEW? (2, 7,44, ¢). 


e (Correctness) For some fiegliible function €(k), for all (,7,a4,c) € Li (f), 


Probz,, [VO(Z, #,a4,¢, 71a) # fe(NI(Z, 7, a4,¢, 7,1r))] < €(k). 


There is a corresponding notion of perfect security, in which there is equality on the privacy 
constraint, and no chance of error on the correctness constraint. 


°For information-theoretic security, one might select a nonasymptotic notion of security: the distance 
between £P, and £5; is at most 2~*, and the chance that the VO differs from F(NT) is at most 22%: 
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2.5 Discussion 


A great many issues have been considered in constructing our definition of secure function 
evaluation. In this section, we draw the readers attention to just a few of them. Greater 
discussion and justification for these notions will appear in the paper of Micali and Rog- 
away [MR91]. 


THE MARRIAGE OF PRIVACY AND CORRECTNESS. Some earlier definitional work treated 
privacy and correctness as separate concerns that could be met independently. One must 
be cautious of approaches like this: in many possible formalizations, protocols exist which 
would be private with respect to one simulator, correct with respect to another simulator, 
but not simultaneously private and correct with respect to any simulator. 

The idea that correctness should be defined by using the same simulator existentially 
guaranteed for privacy was one of the early ideas underlying this work. In fact, at this point 
it seems crucial that privacy and correctness be interwoven: though privacy is a meaningful 
notion in its own right, it is doubtful that a strong notion of correctness is possible without 
its definition being entwine with that of privacy. 


STATISTICAL CLOSENESS FOR CORRECTNESS. A protocol should compute what it is sup- 
posed to compute—and not just something that “looks like” what the protocol is supposed 
to compute. For example, a protocol for collaboratively flipping coins is not an acceptable 
protocol for collaboratively computing range points of a pseudorandom generator. (Pseu- 
dorandom generators are described in the next chapter.) 


REDUCIBILITY. Cryptography is a slippery business. One demonstration of this lies in the 
fact that many plausible definitions for secure function evaluation fail to make the “obvi- 
ous” theorems true (or, if they are true, what their proofs are is unclear). Illustrating this, 
many possible definitions of a secure protocol appear not to provably achieve the following 
reducibility property, informally stated as follows: that a secure protocol for f in the “spe- 
cial” model of computation which is like ours but which provides for the computation of g 
as a “primitive” should remain a secure protocol for f when a secure computation for g is 
inserted in place of using the primitive provided by the enriched model. 

That is, suppose you have designed a secure protocol for some complicated task-— 
computing some function f, say. In an effort to make more manageable your job as protocol 
designer, you assumed in designing the protocol that you had some primitive g in hand (an 
oblivious transfer “box,” say, for implementing a voting protocol). You proved that your 
protocol P% for computing f was secure in a model of computation in which an “ideal” 
computation of the primitive g was provided “for free.” Now you have continued your work 
and designed a protocol P, which securely computes g. One would hope that you obtain 
a secure protocol for f by inserting the code P, wherever it is necessary in P% that g be 
computed. 
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Our definition of security admits such reducibility. However, stating this theorem pre- 
cisely and proving that it holds would take us well afield of our goal. 


ADVERSARIAL AWARENESS. In the ideal computation of a function, the adversary neces- 
sarily “knows” what she has sent off to the trusted party on a particular execution of the 
protocol. She knows that the function will be computed on this value, shuffled in with 
the good players’ inputs. She knows what values, subsequently, are returned to her by the 
trusted party. 

Through the adversary input function, the adversary output function, and our notion of 
correctness, we have required that all of this is directly paralleled in a protocol we call secure. 
In particular, the adversary is “knows” the input she has effectively “sent off” to the network 
to compute on (in the sense that she could easily calculate this 2% value, using AZ); she 
knows that, almost certainly, the function will be computed on this value, shuffled in with 
the good players’ inputs; and, finally, the adversary is aware of what values, subsequently, 
have been effectively returned to her (in the sense that she could easily calculate them, 
using AQ). A failure to mimic any of these properties of the ideal protocol would be a 
significant breach of the abstraction. 


INDEPENDENCE. We wish to ensure the highest possible standard for independence—the 
adversary’s inability to significantly correlate her behavior with the private input values 
held by uncorrupted processors. Our definitions do this, though we shall not in this thesis 
formalize statements which capture the extent to which independence has been obtained. 


CirHaAaAPTER 8 


The Constant-Round Protocol 


The protocol described in this chapter was invented with a goal of minimizing what would 
seem to be the key resource for secure distributed computation—interaction. Of course as 
interaction is minimized, other complexity measures must simultaneously be kept in check. 

This chapter does not prove—or even rigorously state—anything about the protocol we 
exhibit. This is left to Chapter 4. We begin with an overview. 


3.1 Overview 


To develop some intuition, we first look at why interaction rounds were formerly used in 


such excess. 


THE GMW-PARADIGM. In the multiparty protocols of [GMW87, CDG87, GHY87, GV87, 
BGW88, CCD88, BG89, RB89, GL90] and others, the underlying notions of security are 
often quite different, and so are the assumed communication models. Nonetheless, ali of 
them follow the same basic paradigm of Goldreich, Micali and Wigderson [GMW87], which 
we now describe. 

There are three stages to collaboratively compute the value of some function y = 
f(v1,...,@n). (For simplicity, take f to be a Boolean function of n binary strings.) In 
the first stage, each player “breaks up” his private input into pieces, or shares, and dis- 
tributes these pieces. When sharing a value b, for some parameter t, t < n/2, we require 
that no zt players get information about b from the shares received; and yet, the value b is 
recoverable given the cooperation of the “good” players-—even if the “bad” players try to 
obstruct this recovery to the best of their abilities. 

After the sharing stage, a computation stage follows, in which each player, given his own 
shares of the input (71,...,%,), computes his own share of f(21,...,%n). To accomplish 


of 
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this, the function f to be evaluated is represented by a Boolean circuit, C. Thus, in 
Stage 1, each player got shares of the values along the input wires of C. In Stage 2, for 
each gate of the circuit, from shares for the input wires for this gate the parties compute 
in a privacy-preserving manner, the shares for the output wire of this gate. In general, this 
privacy-preserving computation employs interaction. In this way, the parties work their way 
up the circuit, from leaves to root, and eventually hold shares for the value corresponding 
to the output wire of circuit C. 

In the third and final stage, the result of the function evaluation is recovered by having 
the players properly combine the shares held for the output wire of the circuit C. 


THE PROBLEM. In view of even this brief description, it can be seen that all of these 
protocols for secure function evaluation run in unbounded “distributed time”—that is, using 
an unbounded number of rounds of communication. Even though the interaction for each 
gate can be implemented in a way that requires only a constant number of rounds, the total 
number of rounds will still be linear in the depth of the underlying circuit. 

Bar-Ilan and Beaver [BB89] were the first to investigate reducing the round complexity 
for secure function evaluation. They exhibited a method that (for information-theoretic 
security) always saves a logarithmic factor of rounds (logarithmic in the total length of the 
players’ inputs), while the total amount of communication grows only by a polynomial fac- 
tor. While their result shows that the depth of a circuit is not a lower bound for the number 
of rounds necessary for securely evaluating it, the savings is far from being substantial in 
the general setting. Thus, the key question for making secure function evaluation practical 
or for understanding its complexity is: 

How many rounds are necessary to securely evaluate a circuit, while keeping the 
communication and local computation polynomial in the size of the circuit? 


CONSTANT ROUND SECURE COMPUTATION. Many of us believed that more complicated 
functions (i.e., those with greater circuit complexity) required more rounds for secure eval- 
uation. We now know this to be false, for the case of complexity-theoretic secure computa- 
tion: 


Main Theorem — Informal version There exists a protocol which, using a constant 
number of rounds and a polynomial amount of communication, allows its participants to 
evaluate any circuit securely. The protocol works in the model of computation described in 
Chapter 2, in which parties can communicate privately in pairs and can broadcast messages 
to everyone. It assumes the existence of a one-way function. The protocol tolerates any 
polynomial-time adversary who can corrupt fewer than half of the total number of players. 


Informally, the theorem says that interaction is like an atom. Without interaction secure 
function evaluation is impossible; but with a tiny bit of interaction, it is fully possible. The 


formal statement of the theorem above is given by Theorem 4.3.1. 
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A NEW APPROACH. Achieving low round complexity necessitates a break from the gate-by- 
gate approach described above. The protocol described here is the first multiparty secure 
function evaluation protocol which does this. Subsequently, Beaver, Feigenbaum, Kilian 
and Rogaway [BF KR90] also developed a secure function evaluation protocol which does 
not follow the gate-by-gate approach. 


A BIRD’S-EYE VIEW OF THE CONSTANT-ROUND PROTOCOL. The method for achieving 
fast secure function evaluation can be described as finding the right way to generalize the 
older two-party protocol of Yao [Ya86]. His approach—what I call computing a “garbled 
circuit”-——-had been used within the GMW-paradigm for computing the desired “out-going 
shares” of each gate from its “incoming shares” by engaging in many, suitably chosen, two- 
party computations. This use, however, leads to an unbounded number of rounds. We, 
instead, modify the construction “from the inside,” generalizing it to many parties but 
preserving the constant round complexity. 

The idea is to have the community use the limited interaction available to it to construct 
a publicly-known garbled circuit, along with a set of garbled inputs to feed to this circuit. 
Taken together, the garbled circuit and the garbled input are called the garbled program. 
The garbled program is sufficiently “scrambled” that its revelation does not divulge more 
information than what is permissible to divulge. The garbled program is computed using 
the older gate-by-gate approach to secure function evaluation. Once issued, each individual 
player evaluates the garbled program on his own, without interacting with other players. 

The garbled program is defined is a very special way, so as to allow the players to 
compute this object in a way that permits them to perform the brunt of the scrambling 
locally, rather than use intensive interaction to collaboratively scramble the program step- 
by-step. 

To efficiently come up with the garbled program, the players join various pieces together, 
each piece contributed by an individual participant. Of course, no player is trusted to 
contribute a correct piece, so each player uses interaction to prove to the community that 
he has done his work correctly. As usual, verification is simpler than computation, and 
correctness of very deep circuits (evaluated locally by individual players) can be verified by 
small, shallow circuits. These can be evaluated securely in a constant number of rounds 
using the gate-by-gate approach of previous protocols. In the end, the community can be 
certain that it is issuing a correct garbled program, which has been found with very little 
interaction and is evaluated without any interaction at all. 


WHY BOOTSTRAPPING HELPS. In the remainder of this chapter, even some of what is 
described above is abstracted out, as we show how to implement a secure function evaluation 
protocol on top of any other secure function evaluation protocol. In the next chapter, we 
show that if the underlying secure function evaluation is correct and private, then the 
protocol implemented on top of it will also be correct and private. 
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How, intuitively, can we possibly gain something by implementing a secure function 
evaluation protocol on top of another secure function evaluation protocol? Seems like a 
strange strategy. 

In general, if one wants to securely evaluate some function f in a particularly efficient 
manner, one would expect to have to exploit the specific structure of the particular function. 
But in devising a general method of producing secure protocols, the function being evaluated 
is arbitrary, so there would seem to be no structure there to exploit. The bootstrapping 
strategy works because the evaluation of f is implemented on top of the evaluation of a 
function f which is concoted to have a remarkably simple structure—so simple that f can 
be evaluated securely in constant rounds. Thus the arbitrary, “structureless” function f 
necessarily does have enough structure to allow it to be distributively evaluated efficiently. 


IDEAS FROM WHICH THE PROTOCOL SPRINGS. As mentioned, the idea of performing two- 
party computation by using a garbled circuit is due to Yao [Ya86]. 

We require the use of a secure function evaluation protocol, as developed by [GMW87, 
BGW88, CCD88, RB89]. To achieve constant round complexity, we demand that constant- 
depth circuits can be evaluated in constant rounds; the exact statement of what is required 
is given by Theorem 4.1.1. Any of the information-theoretic secure protocols mentioned 
above, [BGW88, CCD88, RB89], can be implemented to have this property. We note that 
the security of the constant round protocol, though, does not depend on situating it on top 
of an information-theoretic secure protocol; a complexity-theoretic secure protocol would 
do as well. 

The protocol of [Ya86} required the intractability of factoring. This assumption was re- 
duced to a trapdoor permutation in [GMW87]. The protocol we develop assumes the mildest 
of common cryptographic assumptions—the existence of a one-way function. However, this 
relaxation in assumptions is not new. Galil, Haber and Yung [GHY87] had already showed 
that a pseudorandom generator suffices to produce the underlying “encryptions” for the 
garbled circuit that were formerly achieved using public-key cryptography in the [GMW687] 
protocol. In ([BG89], Beaver and Goldwasser explicitly recognize that a one-way function is 
adequate for the job. 


A DETOUR. We have managed to state the general strategy for achieving fast secure function 
evaluation without even hinting at what a garbled program looks like or how it is evaluated! 
Before we rectify this, we take a short detour and describe a central tool needed to answer 
these question: the tool is a pseudorandom generator. 


3.2 Pseudorandom Generators 


A pseudorandom generator deterministically stretches a short, truly random “seed” into 


a longer “pseudorandom” string. The distribution induced on the pseudorandom strings 
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when the seeds are sampled from uniformly at random is such that the pseudorandom 
output “looks random” with respect to any polynomial-time computation. 

This notion of a pseudorandom generator was first defined and investigated by Blum and 
Micali [BM82], and by Yao [Ya82b]. These authors showed that pseudorandom generators 
exist under appropriate complexity assumptions. 


Definition 3.2.1 A pseudorandom generator is a polynomial-time computable function G : 
“* — &* taking k-bit strings to Q(k)-bit strings, Q(k) > k, such that the k-indexed 
ensembles EG(U;,) and EUVgx) are computationally indistinguishable. 


Call the function Q(k) in Definition 3.2.1 the stretch of the generator G. The following 
theorem appears in Boppana and Hirschfeld [BH88]. It says that the ability to stretch the 
truly random seed just a little implies the ability to stretch it a lot. 


Theorem 3.2.2 If there exists a pseudorandom generator with stretch k+1, then, for any 
polynomial Q(k) > k + 1, there exists a pseudorandom generator with stretch Q(k). a 


A major effort has gone into weakening the conditions known sufficient for the existence of 
a pseudorandom generator, including the work of Levin [Le85], and of Goldreich, Krawczyk, 
and Luby [GKL88]. This effort has culminated in the work of Impagliazzo, Levin and Luby 
{ILL89], and Hastad [Ha90]. They characterize nonuniform and uniform pseudorandom 
generation by the existence of nonuniform and uniform one-way functions, respectively. 
(But recall that we are limiting the scope of our definitions to nonuniform notions.) We 
now define a (nonuniform) one-way function. Informally, this is an efficiently computable 
function whose inverse is computable only a negligible fraction of the time. 


Definition 3.2.3 A one-way function is a polynomial-time computable function f : 4* > 
&* such that for any polynomial-time “inverting” algorithm I and any infinite string ay, 


e(k) = Probsev, [1(1*, f(z), ar) € f-(F(2))] 
is negligible. 


The existence of a function f’ satisfying the definition above turns out to be equivalent to 
the existence of a function f satisfying the apparently weaker condition that any inverting 
algorithm should fail to invert f a significant fraction of the time—more precisely, that 
there exists a constant c such that for any inverting algorithm J and any infinite string a, 


A(k) = Probzeu, [1(1*, f(a), a1) ¢ f-(F(#))] 


is at least n~° for all sufficiently large n [Ya82b]. Similarly, it is also equivalent to allow the 

inverting algorithm to be a probabilistic polynomial-time algorithm; the probability that I 

successfully inverts is now taken over the inverting algorithm’s coins as well as over x € U,. 
A theorem mentioned previously is the following: 
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Theorem 3.2.4 ({ILL89, Ha90]) A pseudorandom generator exists if and only if there 


exists a one-way function. | 


As a simple example of the results cited, consider the multiplication function 


f(r122) = 21:22, 


where |x| = |z2| + 6, 6 € {0,1}, and 2, - x2 is the product of z, and z2, treated as binary 
numbers. Suppose that every polynomial-time algorithm fails a fraction n~!° of the time (for 
big enough n) to split a number z into numbers 2, and x2 with 2,22 = z and |x| = |r2|+ 6, 
6 € {0,1}, when z is the product of random numbers of lengths varying by at most one. 
Then there exists a pseudorandom generator stretching length-k strings to length 2nk + 2 
strings, where 7 is any fixed polynomial in k. 


3.3. High-Level Description 


We have said that constant-round secure function evaluation is achieved by efficiently issuing 
to each player a garbled circuit and a set of garbled inputs at which to evaluate this circuit. 
This section informally describes what a garbled program looks like, how it is evaluated, 
why it is plausible that it can be computed quickly, and why it might be issued to the players 
without compromising their private inputs. The next section more formally describes how to 
collaboratively compute a function f given a protocol for computing some related function jf, 
instead. 


THE SET-UP. The players want to collaboratively evaluate some function. This function 
must be represented somehow; we represent it by a Boolean circuit C. We assume that C 
is made up of only two-input gates. Though the gates have bounded fan-in, they may have 
unbounded fan-out. Each player knows the input bits along some of the input wires to C— 
namely, player 2, who possesses private input 2;, knows the |z,| bits along the input wires 
which take z;. The community wants to learn the bits induced along the output wires. 

Figure 3.1 is an example of a circuit three players may want to collaboratively evaluate. 
The circuit has two gates and five wires. Players 1, 2, and 3 provide the bits 71, 2, and x3 
along wires 1, 2, and 3, respectively. Thus the players are trying to evaluate the function 
f(@1, 2,23) = 2129 V 3. We will suppose that 2; = 0, v2 = 1, and 23 = 1, so the players 
should compute the bit 1. 

(In this example, each player just provides a single bit, and there is only a single bit of 
output. But neither of these facts will be relevant to the method we describe.) 


EVALUATING AN (UNGARBLED) CIRCUIT. How would a circuit C normally be evaluated? 
Here is one way to describe it. 
See Figure 3.2. In the circuit C, each wire carries one of two possible signals—the formal 
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Figure 3.1: A circuit for three players to distributively compute 2,22 V 23. 


string O or the formal string 1. The two possible signals are the same for each wire, and 
everyone knows what the two signals associated to a wire are. 

Each signal has a corresponding, “publicly-known” semantics. The 0-signal means that 
the wire has semantics 0 (or “false”), while the 1-signal means that the wire has a semantics 
of 1 (or “true”). 

If you know the signals along the incoming wires of a gate, you can mechanically prop- 
agate a signal to the out-going wire of the gate. For example, an AND gate with incoming 
signals of O and 1 gets an out-going signal of 0. In this way, signals propagate up the circuit, 
from input wires to the output wires, eventually defining signals for all output wires. Since 
the signals have a fixed, known, semantics, the circuit has then been evaluated. 


EVALUATING A GARBLED CIRCUIT. Evaluating a garbled circuit is not so very different. 
Once again, there will be wires, gates, and signals, and these will mirror the structure of 
the corresponding “ungarbled” circuit. See Figure 3.3, which depicts a garbled circuit, and 
information related to it. 

Wires will still carry one of two signals—but this time, the signals will not be the 
strings O and 1. Instead, each wire w will have longer strings associated to it, signals s¢ 
and s?. These will be random strings of length nk + 1—random except that signal s¢ will 
always end in a 0, and signal s¥ will always end with a 1. 

Before, the signals associated with a wire were publicly known, and the same two signals 
were associated with each wire. Now, the signals associated with a wire will be secret, and 
they will vary from wire to wire. 


Before, the two signals had a fixed semantics, 0 meaning 0 (false) and 1 meaning 1 
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Figure 3.2: The circuit and its input. Each wire caries one of two signals, 0 or 1, with 
associated semantics 0 + 0 and 1 1. To compute, signals are propagated mechanically 
up the circuit. 


(true). Now, the signals will have a secret, “hidden” semantics: s# having associated 
semantics A” and s¥ having associated semantics \”. For wires other than the output 
wires, this semantics is random, and is not known by anybody. In Figure 3.3, the signals s} 
and si have been given the semantics 0 and 1, respectively, while s3 and s? have semantics 1 
and 0, respectively. 

Just as evaluating an ungarbled circuit consists of learning the correct signal for each 
wire by mechanically propagating signals up the circuit, evaluating a garbled circuit consists 
of learning one of the two signals associated with each wire, and propagating these signals 
up the circuit. Initially, you will hold (that is, you will “know”) one of the two possible 
signals for each input wire—you will hold the signal with the correct semantics for this 
input wire. Holding a signal sf for a wire w will correspond to that wire having semantics 
of A“®?, Given the two incoming signals for a gate, a method will be provided allowing you 
to learn the correct out-going signal for that gate. 

For example, in Figure 3.3, knowing sj and s? “means” that the left and right incoming 
wires to Gate 1 carry 0 and 1, respectively. Consequently, in evaluating this “garbled gate,” 
the players should learn the signal s?, since this is the signal for the out-going wire which 
carries the semantics of 0A 1 = 0. 

As mentioned, the sf and s? signals are concocted to be differentiable: we asserted that 
the last bit of sf is a O and the last bit of s? is a 1. Thus these signals are referred to as 
the even and odd signals, respectively. If you know a signal for a wire, you know whether 
you possess the even or the odd signal for the wire, but this tells you nothing about the 
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Figure 3.3: A sample garbled circuit (the eight gate labels) and garbled input (the three 
signals that are fed in along the input wires). Also shown are the two signals (secretly) 
associated with each wire, and their corresponding (secret) semantics. 


underlying semantics of the wire, because this was chosen at random independent of the 
signal being even or odd. 

An exception to this is made for output wires, for which we want the semantics to be 
public. We simply assert that the even signals for these wires have semantics of 0, and 
the odd signals have semantics of 1. Now when a player has computed the signals for the 
output wires of a circuit, he has also computed the “semantics” of the circuit’s output. 

In evaluating the circuit of Figure 3.3, each player initially knows 3), 32, and s?. The 
first two of these are combined and—somehow—each player learns s#. Then s{ and s? are 
combined and—somehow—each player learns s°. Since this signal belongs to an output 
wire and is odd, the circuit evaluates to 1. 


How SIGNALS PROPAGATE ACROSS A GATE. What, exactly, is this mechanism that allows a 
player, given knowledge of two incoming signals to a gate, to compute the correct out-going 
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Figure 3.4: A closer look at the signals associated with the wires of Gate 2, and their 
corresponding semantics. Each signal consists of n length-k strings, and one additional bit. 


signal for the gate? 

Each gate g of the garbled circuit provides “help” for accomplishing this task for gate g. 
The help is in the form of a table of four strings of length nk +1. Each of these strings is 
called a gate label. The garbled circuit is the collection of all of the gate labels for all of the 
gates. 

The four gate labels associated with gate g are written Ag,, Ag,, Af), and Af,. If you 
possess two even incoming signals for gate g, then Ag, allows you to compute the correct 
out-going signal; if you possess an even signal for the left incoming wire of gate g and an 
odd signal for its right incoming wire, then Ag, lets you recover the out-going signal; and 
so forth. 

We now describe how the out-going signal is computed from the incoming signals and 
the gate labels. 

The signals for a wire are not treated atomically. Rather, each signal is considered as 
consisting of n strings of length k, together with one more bit that specifies whether this 
signal is even or odd. Figure 3.4 shows the makeup of the signals for Gate 2 of Figure 3.3, 
together with their semantics. 

Each of the n “pieces” of each incoming signal serves as the seed of a pseudorandom 
generator G stretching k bits to 2(nk + 1) bits, where 7 is a fixed polynomial in k which 
bounds the number of players, n, in terms of the security parameter used by the algorithm, k. 
(For concreteness, we will later select n = k'°, quite arbitrarily.) Define Gj and G{ by 
G(s) = Go(s)Gi(s), for |Go(s)| = |Gi(s)| = ak +1, and set Go(s) = Go(s)[1 : nk + 1] and 
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Figure 3.5: The pseudorandom generator G, stretching k bits to 2nk + 2 bits, for 


n = 7n(k) a fixed polynomial in k. The map G defines Go(s) = G(s)[1 : nk + 1] and 
G(s) = G(s)[mk + 2: nk + nk 4 2]. 
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Figure 3.6: How the out-going signal for a gate is determined from the two incoming signals. 


G;(s) = Gi(s)[1 : nk + 1]. See Figure 3.5. 

In evaluating the garbled circuit, for each wire incoming to some gate g, either Go 
or G, is computed at each of the n pieces of the incoming signal carried along that wire. 
To illustrate, suppose that you possess two even signals coming into a gate g. That is, 
both of the incoming signals are strings of length nk + 1 which end in 0. Then each of the 
two signals, minus the last bit, is disected into n k-bit long strings. Apply Go to each of 
these 2n strings to get 2n strings of length nk + 1. The bitwise exclusive-or of all of these 
images, also exclusive-or’ed with A§,, is the desired out-going signal for gate g. 

More generally (had the signals not both been even), the out-going signal is computed 
as follows. If the left incoming signal to gate g has parity a and prefix o,---a, (each a; 
of length &); and the right incoming signal to gate g has parity b and prefix 7; ---7, (each 
7; of length k); and the gate labels for this gate are Apo, Aoi, A1o, Aii; then the out-going 
signal is defined to be 


G(s) = Go(s)Gi(s), for |GO(s)| = |Gi(s)| = 2k + 1, and set Go(s) = Go(s)[1 : nk + 1] and 
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This is illustrated in Figure 3.6. 

The string A%, can be thought of as the encryption of the out-going signal with the 
correct semantics given that both incoming signals were even. To decrypt this encryption, 
you must hold both of the two even incoming signals. 

More generally, the convention on the signals being even and odd lets you know which of 
the four gate labels is meaningfully decrypted given the “secret key” (01 +++, @, T,+*+Tn 6). 

We have specified what the garbled circuit looks like: it is the collection of A‘,-values. 
The garbled input is the collection of those signals which carry the correct semantics for 
each input wire of the circuit. In Figure 3.3, the garbled input consists of the strings sj52s?, 
while the garbled circuit is Aj,A}, Al, A}, Aj,A?, A?,A?,. The garbled circuit together with 
its garbled input is called the garbled program. 

We have now described how to evaluate a garbled program, and how to understand the 


result. 


WHY CAN A GARBLED PROGRAM BE FOUND QUICKLY? For any choice for the even and 
odd signals of length nk + 1 for the wires of the circuit C’, and for any semantic assignment 
w t+ A” for these signals, the gate labels for each gate are well defined so that the gate 
computes correctly with respect to the assigned semantics. For example, in Figure 3.4, we 
must arrange that 


Abo = Go($o1)®++* BGo( Son) ® Go(s}1)®--: @Go(sin) ® sf 


for the garbled Gate 2 to compute correctly on two even incoming signals. 

Though in this section we will not write out the general expression for what A‘%, should 
be, it is clearly a simple function of the signals and semantics for the three wires that touch 
gate g. In particular, the gate labels depend only on local information. This means that in 
calculating the garbled circuit, all the gate labels can be calculated in parallel. Since signals 
and their semantics are selected randomly, the calculation of the garbled circuit completely 
parallelizes. This will mean that while the communication complexity for computing the 
garbled circuit depends on the size of the circuit C’, the number of rounds will not. 

Thus to achieve constant rounds the key is to ensure that the calculation of a single set 
of gate labels can be accomplished in constant rounds. It is in order to accomplish this that 
we have treated signals as consisting of n separate seeds to the generator G. In constructing 
the garbled circuit, each player will be responsible for computing G on “his own” portion 
of each signal. That is, each player 7 will be required to locally compute the image under G 
of the i” piece of each signal; and he will enter this information into the collaborative 
computation. For example, in Figure 3.3, player :—if honest—selects ten random length k 
strings sg,, where w € [1..5], 6 € {0,1}, applies G to each of these, and enters all of this 
data into the collaborative computation. Applying the generator G to the strings may be 
time-consuming—but this computation is done locally, not distributively. It is in this way 
that the brunt of the scrambling operation is performed locally. 
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Given the images of the seeds under the generator and the ”-values specifying their 
semantics, the calculation necessary to compute the gate labels is fixed and straightforward; 
it is not surprising that this can be performed efficiently. 


Why IS THE PROTOCOL PRIVATE? The technical answer that “the simulation goes through” 
is not particularly satisfying! We try to give some intuition why the strategy outlined might 
be private. 


The intent is that knowledge of two incoming signals for a gate gives rise to knowledge 
of the correct out-going signal, and nothing else that is meaningful. So if you are magically 
handed a garbled circuit and a garbled input to feed to it, you should learn only a randomly 
selected signal for each wire not an output wire. For each output wire, you should learn 
a random signal of the “correct” semantics. Apart from the output wires, knowledge of a 


single signal for a wire should have no discernible meaning. 


In some sense, the secure collaborative computation of the garbled program does amount 
to magically being handed the garbled circuit and the garbled input—except that the signals 
are not entirely secret, since each player knows one piece of each signal (the piece that player 
“was responsible for”). The main concern, then, is that the garbled program does divulge 
extractable information, even if taken together with those pieces of signals a bad player 
might already know about. That is, as a dishonest player, you know one complete set of 
signals for the input wires (from knowing the garbled input), and you know those pieces of 
various other signals that your dishonest friends have told you about. But, since there is 
some honest player who has not told you the seeds he was responsible for, you are denied 
knowledge of some piece of each incoming signal that is not a garbled input. Intuitively, 
in order for one of the gate labels to be meaningful, you must not be denied knowledge of 
any of the 2n seeds whose images under the generator are exclusive-or’ed to decrypt the 
out-going signal. 


In fact, replacing a gate label for which you lack a seed required to “decrypt” that 
gate label with a truly random gate label does not give rise to a noticeable change in 
distributions. (Of course, we will be proving this.) Three of the four gate labels for each 
gate will be like this, and so all of these can be exchanged with truly random strings without 
a noticeable change in distributions. But this new distribution—a distribution on “fake” 
garbled circuits—is easily generable. So, releasing a garbled circuit reveals no significant 
information, insofar as an indistinguishable “fake” garbled circuit can be released if one 
knows only what the garbled circuit ought compute. 


In the next section, we repeat the protocol more formally, without attempting to provide 
additional intuition. 
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3.4 The Protocol 


NOTATION. We fix notation to be used throughout the remainder of the thesis. Let G denote 
a pseudorandom generator that stretches a k-bit string s to a 2(nk + 1)-bit string G(s), 
where n = k!° bounds the actual number of players, n, in terms of the security parameter, k, 
which will be used by the protocol. (The constant 10 is an arbitrary constant.) Let Go 
and G, be given by G4(s) = G(s)[1: mk + 1], and Gi(s) = G(s)[nk + 2:nk + 24 2k + 2], 
with Go = Go{1:nk + 1] and G, = Gi[1:nk + 1]. 

We consider the collaborative computation of a string-valued function f, : (Z4)" > U!. 
This function is represented by a circuit C, : (=°)" — E!, with f.(21-++@n) = C.(a, +++ ay). 
A description of this circuit appears on the common input ¢ = 1 #1°#1'#:1'#1"#C,. 
The circuit C, has [ gates, which are labeled 1,2,...,1, and it has W wires, which are 
labeled 1,2,...,W. The gates are taken to be two-input gates of arbitrary functionality and 
arbitrary fan-out. Each gate has distinguished left and right incoming wire. The numbering 
of wires is chosen so that the input wires are wires 1,...,n£, and the output wires are wires 
W —14+1,...,W. The j-bit of private input x; appears along input wire €(i—1)+ J, and 
the j*-bit of the output y appears along output wire W —1+ 7. 

In the description of the protocol that follows, the index i ranges over the players, 
i € [1..n]. The index w ranges over the wires, w € [1..W], or—when indicated—some subset 
of these wires (like the input wires). The index g ranges over the gates, g € {1..I’]. 


COMMENTS ON THE PROTOCOL. The following remarks and terminology will be used in 
the proof presented in Chapter 4, or are otherwise useful in understanding the protocol. 

e When run on common input ¢ = 1'' #1"°#1°#1'#1"#C, with k’ as the security 
parameter specified by c, the “true” security parameter k used by the players in 
the protocol is not necessarily k’—because we insist that k be at least a polynomial 
fraction of |c|. This is necessary because the adversary is given time polynomial 
in |c|, rather than time polynomial in k. We enforce this requirement by saying that 
k = max{k’,|e|!/!°}, where 10 is an arbitrary absolute constant. Because of this 
convention, n is bounded above by a fixed polynomial in k, n < i(k) = k?°. 

The garbled circuit is the collection of gate labels issued to the players, AZ, € U"*t?, 


The garbled input is the collection of signals o” € U"*+! issued to the players, one 
for each input wire w. The garbled program is the garbled circuit together with the 
garbled input. Thus a garbled program looks like 


y= Ajo As: Ato Ai; ae Ago At1 AtoAn a ee zi, 


where / = (4P + n£)(nk + 1). 
e The mapping specified by Step 1 from player inputs # and player random coins 7 
to the garbled program 4%, is referred to as the function f. The function f can be 
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considered as a map from (D‘)" to ¥!, for £ = £+ p, with p = 2kW+W —l. Of course 
f is actually a function family; it depends on the common input. 

The mapping specified by Step 2 of the protocol, from the garbled program 4 € >! to 
the string y € = to which it evaluates, is called the evaluation function, Eval. We 
write y = Eval(c, g). 

In the evaluation of a garbled program 4%, the collection of W signals which come to 
be held are called the on-path signals. The other W signals are the off-path signals. 
The collection of I’ gate-labels which are used for computing the on-path signals—one 
AS, for each gate g—these are called the on-path gate labels. The other 31 gate labels 
are called the off-path gate labels. 

Evaluating a garbled program entails learning the on-path signals and outputting the 
parity of each on-path signal for each output wire, in the proper order. 


to the garbled program 4g, is referred to as the function f. The function f can be 
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Step 1: Collaboratively compute the garbled program @. 


Common Input: The shared string c = 1° #1" #1'#1'#1"#C. 
Private Input: Each player 7 has private input 2; € L*. 
Coin Tosses: Each player i uses random coins r; € S?*W+W-!, 
Compute: Players compute gate labels A’, A§i, A{fo, Aj, € U"*t! and input 
signals o” € U"*+!, for g € [1..T] and w € [1..né]. 
Let k = max{k’,|c|'/1°}. The parties information-theoretically |(n — 1)/2|-securely 
compute (with security parameter k), gate labels and input signals, defined as follows: 
(a) (i) Each string 7; defines length k strings s},, s,,...,3%,s® and bits \},...,A”~! 
by asserting that r; = si,st,.--sWs¥ \}...¥-" 
(ii) The private inputs z,,...,2, define the bits b',...,b" associated with each 
input wire, according to b!.--6" = 2,-+-2,. 
(iii) For b € {0,1}, let sf = s¥,--- 5%, b. 
Comment: s§ and s are the even and odd signals associated to wire w. 
(iv) Define 
\ = ee forl<w<W-4l, 
0 for W-l4+1<w<W 


Comment: \” is the semantics of signal s%, and \” is the semantics of signal s¥. 
For each input wire w of the circuit, w € [1..né], the string o” is given by 


o” = Shegre- (3.2) 


Comment: That is, 0” = sq if b” = A”, and o” = s? if b* # ”. In general, sf). is the 
signal for wire w which carries semantics b. 

For each gate g of the circuit, g € [1..T], the strings Af), Aj,;, Afp and Af, are 
defined as follows: let @ denote the function computed by gate g, suppose the 
left wire is wire a, the right wire is wire 3, and the output wire is wire y, for 
a, 8,7 € [1..W]. Then, for a,b € {0,1}, define the gate label A%, by 


Al, = Gs(st)®---@Gs(s3,) @ Ga(s1)@-++OGa(s5,) @ 


3 
S[(A* @a)@(AP BOAT (3.3) 


Comment: A°@a is the semantics of the left wire if you possess a parity-a signal for the 
left wire, and \°@b6 is the semantics of the right wire if you possess a parity-b signal for the 
right wire. In this case, the gate should output the signal of semantics (A*@a) ® (A°@b), 


which is signal $/(,.g)@(,s@b)]oav 


Figure 3.7: Step 1: the parties collaboratively compute the garbled program 9. 
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Step 2: Locally evaluate garbled program 9, computing y = Eval(#). 
Common Input: The shared string c = 1" #1" #1°#:1' #1" #C. 
Input: A garbled program 9, i.e., gate labels A%,, A3,, Afy, Af, € E+}, 
and input signals o” € U"*+!, for g € [1..T], w € [1..né]. 
Output: The string y € ! that this garbled program “evaluates to.” 


Let k = max{k’,|e|!/!°}. Each player i behaves as follows: 


Initially, player i is said to hold the signal 


o” =o} ---a¢ |sb(o%), 


for each input wire w, where |o¥| = --- = |o%| =k. 


Consider a gate g, having left input wire a, right input wire 8, and output wire y, with 

a,B,y € [1..W]. Suppose inductively that player i holds the signal o% = of ---o% a 

for wire a, and the signal o? ---o 6 for wire B, where |o%| = --- = |o?| = lof] = 
-- = |o?| = k and a,b € {0,1}. Then player 7 computes and is said to hold the signal 


a’ = G,(o%)@---OGi(o2) ® Gal(of)@---OGi(o%) © A%, (3.4) 


for wire y. In this way, o” values are computed for each wire w of the circuit. 
When a value o” is held for each wire w of the circuit, each player i outputs 
y = Isb(o—'*") ... Isb(a”) 


as his private output. 


Figure 3.8: Step 2, in which the players, on their own, evaluate the garbled program 4. 


CHAPTER 4 


Proving the Protocol Secure 


4.1 Introduction 


The protocol described in Chapter 3 is not specified fully because we have not said how to 
implement the secure function evaluation on which it rests. All we have specified is what 
we want to collaboratively compute, and how a computation of this is used to define each 
player’s private output. 

We will not remedy this; in fact, we will exploit it. Our strategy has been to abstract out 
the specifics of the already very complicated information-theoretically secure collaborative 
computation, and argue that—whatever its implementation—if it securely computes the 
function f that it is designed to compute, then the protocol as a whole securely computes 
the function f that it was designed to compute. 

Here, precisely, is what we will assume: that existing protocols—those of [BGW88, 
CCD88, RB89|—can be used as the basis for proving Theorem 4.1.1, below. We do not say 
what particular protocol is used—though, for concreteness, we state the theorem with the 
bound on fault-tolerance of the [RB89] protocol, t = |(n—1)/2]. If a protocol with a weaker 
bound on fault tolerance is used, this bound is simply mirrored as the fault-tolerance in 
Theorem 4.3.1. If an error-free protocol is employed as the basis of Theorem 4.1.1, there 
will, correspondingly, be no error in the correctness constraint for the complexity-theoretic 


constant-round protocol. 


Theorem 4.1.1 Let f = {f.} be a string-valued function family, in which each f, : 
(x%)"« — Lie is described by a circuit C., with f.(2,++-2n,) = Ce(gi(21) +++ Gn-(2n.)) 
where g : &* X N — &* is polynomial-time computable and {C,} is a family of constant- 
depth circuits, each containing only two-input NAND-gates and unbounded fan-in XOR- 
gates. Then, for some absolute constant R, there is a polynomial-time, R-round protocol P 
which information-theoretically t-securely computes f, where t = |(n — 1)/2]. a 
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More general statements than the one above are possible; this one is tailored to our specific 
needs. 

Theorem 4.1.1 says something more general than that a function can be information- 
theoretically securely computed in constant rounds if it has constant-depth circuits. Rather, 
it says that this is possible if each player need only apply a polynomial-time function to 
his private input, and then the result of this computation is the input to a collaborative 
computation of a function having constant-depth circuits. 

The intuition why Theorem 4.1.1 holds is the following. Secure function evaluation 
using the gate-by-gate approach was sketched in Chapter 1, and, for constant depth cir- 
cuits, protocols employing this approach require a constant number of rounds. Further- 
more, because of the specifics of the mechanisms for secure function evaluation developed 
in [BGW88, CCD88, RB89], not only can the shared out-going bit for a bounded fan-in 
gate be computed from the shared incoming bits in a constant number of rounds, but this 
is possible for unbounded fan-in XOR gates, as well.! For the function g that each player is 
“asked” to contribute an image under, each player shares the preimage as well as the image. 
He then “proves” to the community that the shared image was properly computed from 
the shared preimage. Though this proof will use an amount of communication which grows 
with the depth of a circuit for computing g, it requires only a fixed number of rounds. 

How does Theorem 4.1.1 apply to us? Basically, the function we collaboratively evaluate 
in Step 1 of the protocol of Chapter 3 does indeed factor into a “hard” part, g—which play- 
ers evaluate locally—and an “easy part,” C.—which the players collaboratively evaluate. 
Details specifying this decomposition are given in the proof of Theorem 4.3.1. 

Since the round complexity for computing the output y in our protocol is precisely the 
round complexity for computing the garbled program g, and since the local computational 
complexity of our protocol as a whole is within a polynomial factor of the local compu- 
tational complexity for just computing g, Theorem 4.1.1 assures us (after setting up the 
appropriate language) of having specified in Chapter 3 a constant-round, polynomial-time 
protocol, P. However, showing that P t-securely computes f, is not a small task. In Sec- 
tion 4.3 we do this. First, in Section 4.2, we establish some preliminaries needed for the 
argument. 


4.2 Preliminaries 


In this section we collect up some facts which will be useful in proving our main result. 
Perhaps the most basic fact we require is that indistinguishability of ensembles defines 


an equivalence relation. In particular, indistinguishability is transitive (reflexivity and sym- 


1 Alternatively, the result of Bar-Ilan and Beaver [BB89] allows any function with log-depth circuits to 
be securely evaluated in a constant number of rounds. The unbounded fan-in XOR gates could thus be 
replaced by a complete binary tree of bounded fan-in XOR gates, and then this result applied. 
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metry are obvious). 


Proposition 4.2.1 Suppose R and S are computationally indistinguishable ensembles, and 
suppose S and T are computationally indistinguishable ensembles. Then R and T are 


computationally indistinguishable ensembles. 


Proof: The proof is a gentle introduction to a standard cryptographic argument. Suppose 
for contradiction that R = ER,(w) is computationally distinguishable from T = ET;,(w), 
as ensembles over a common parameter set CL = {L,}. Then there is a polynomial-time 
distinguisher D*, a polynomial Q, and a collection of strings {w, € L,}, such that 


JED(1*, Ri(we), we, a) — ED(1*, Ty (we), we, a)| > 1 / Q(k) 
for infinitely many k € N. By the triangle inequality, for each such k, either 

IED(1*, Ry (we), we, @) — ED(1*, S,(we), we, @)| > 1/ 2Q(k) 
or 

|ED(1*, Se(we),we, a) — ED(1*, Ty, (we), we, @)| > 1 / 2Q(k) 


(or both). Thus either there is an infinite collection of k € N such that 
JED(1*, Ry (we), We, @) — ED(1*, 5, (we), we, a)| > 1/ 2Q(k), 
or there is an infinite collection of k € N such that 
JED(1*, S,(we), we, @) — ED(1*, Ry (we), we, a)| > 1 / 2Q(k). 


In the former case, FR is distinguishable from S, and in the later case, S is distinguishable 
from T. This contradicts the theorem’s assumption. a 


> NoTaTion. The notation in the proof above, with all four argument to D, gets a 
bit tiresome. So we will sometimes simplify expressions such as D(1*, Ry(we),we, a) to 


D(Ri(w)). 


If you can not distinguish ensembles R and S based on a single sample, then you can not 
distinguish R and S based on many sample points, either. (Recall that we are only dealing 
with nonuniform indistinguishability.) The proof is implicit in Yao [Ya82b], and follows 
the now standard “probability walk” argument, which we shall use again in the proof of 
Theorem 4.3.1. 


Proposition 4.2.2 If ensembles R and S are computationally indistinguishable over L = 
{L,}, then, for any polynomial Q(k), R° and S@™) are computationally indistinguishable 
over LO) = {L2}, 
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Proof: Assume for contradiction that R@™) and S$?@) are computationally distinguishable. 
Then there is a distinguisher D*, a polynomial gq, an infinite set A’, and a collection of 
strings {w,} such that 


JED(Ri(we)) — ED(Se(we))| 2 1/ a(k) 


for all k € K. We use D and a to construct a distinguisher D? for distinguishing R from S. 

For i € [0..Q(k)] and w € Lg, define Ti(w) = Ry(w)'S,(w)e)-*, Note that T?(w) = 
Si(w), and T°“(w) = Ri(w). By the triangle inequality, for each k € K there must exist 
a gx € {1..Q(k)] such that 


v(k) = |ED(T$*-"(we)) - ED(Tf*(we))| > 1 / Q(k)a(k)- 


(Informally, we have taken a “probability walk” between R,(w,) and S,(w,), using T}(w,) 
to specify a set of steps that take you from the one space to the other. Since the two 
endpoints have significantly different expectations under D, some step in between must 
have associated to it a nonnegligible “jump” in the induced expectations.) 

Consider a “distinguisher” Di»,3,}, where each 75, € (E*)@)-!, This distinguisher 
behaves as follows: it takes a sample x (which can be thought of as being either R,(w,;)- 
distributed or S,(w,)-distributed), and it computes D(1*, (ri --- rg*~tasgtt? ... 8?) wy, a). 
Observe that if each ri is drawn according to R,(w;,), and each s} is drawn according 
to S;,(w,), then 


v(k) |Ex,2, ED x, 3,3(Re(we)) — Ex 2, ED ex, 3,3 (Se(we))| 


Ex, 4, JED {a 2,3(Re(we)) me ED 47,3,3(Se(we))| : 


1A 


Since the average of a bunch of elements cannot exceed the maximum of those elements, 
the equation above implies that there exists, for each k, particular values rj,--- ae and 


gee ees sett) such that 
Wk) < |EDeray(Re(we)) — ED er.) (Se(we))| - 


Letting @ reasonably encode the {g; }-values, these {7,5,,}-values, and the infinite string a, 
we have constructed a distinguisher D? which, along the infinite set K, distinguishes R 
and S by at least the inverse polynomial 1 / g(k)Q(k). This is a contradiction. a 


We draw the following immediate conclusion to Proposition 4.2.2, where n = k'° (or any 
other polynomial in k): 


Lemma 4.2.3 Let G: D* — 0?"*+? be a pseudorandom generator, and let Q(k) be a poly- 
nomial. Then the k-indexed ensembles EU(2ar42)q(x) and E[G(U;)]@ are computationally 
indistinguishable. | 
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4.3. Proof of the Main Theorem 


Our goal is to show the following: 


Theorem 4.3.1 (Main theorem—string-valued computation) Assume a one-way 
function exists, and let f = {f.} be a string-valued function family in which each 
fe: (&%)"* = Ze is described by a circuit C. for computing it. Then, for some absolute 
constant R, there is a polynomial-time, R-round protocol P that t-securely computes f, 
where t = |(n — 1)/2]. 


We emphasize that the protocol P which Theorem 4.3.1 asserts the existence of is a fixed 
protocol: in our formulation the common input contains a description of the function the 
protocol distributively evaluates. Though the polynomial that bounds P’s running time 
in terms of the length of the common input has degree which depends on the underlying 


one-way function, the constant R does not depend on this. 


Proof: We have described the protocol P in Chapter 3, given a protocol for information- 
theoretic secure function evaluation. We must establish that this protocol securely com- 
putes f. This entails exhibiting a simulator S$ = (S,AZ,AQO), and showing that the simu- 


lator “works” to establish P’s privacy and correctness. 


Part 1: Strategy, and exhibition of the simulator S. 


A MENAGERIE OF PROTOCOLS, SIMULATORS, AND ORACLES. To describe the simulator S 
and prove that it works, we will introduce some extra terminology. There are sufficiently 
many terms that the table of Figure 4.1 may help the reader keep them straight. We begin 
by defining the first row of terms in this table, taking a closer look at the secure computation 
of Step 1. 


THE PROTOCOL P. In Step 1 of the protocol, a player i gets private input z; € D¢ and 
common input c = 1*'#1"#14#1'#1"#C, where C specifies [, W, and the topology of 
a circuit on W wires and IT gates, obeying the conventions indicated on Page 70. He 
computes k = max{k’, |c|*/!°}, p= 2kW+W —1, 6= + p, 1 = (41 + né)(nk 4 1), and flips 
coins r; € L?. He then runs a protocol P for secure function evaluation on private input 
a;r; € Sé and common input é = ein ge gin #C, where C is a certain constant- 
depth circuit of two-input NAND gates and n-input XOR gates, a description of C being 
efficiently computable from c. Circuit C' specifies the function f which protocol P computes 
by asserting that 


F(airi,-++,2nTn) = C(gi(cr171),**+59n(€2nTn)); 
where 


gi(ewiri) = tirvG(9o,)G(s3,) ++ GC 80 JG( si )s 
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P The protocol which t-}| $ Simulator for this} O = O(Z7?, #; f), the ora- 
securely computes f (z?). protocol. cle for the simulator S. 


P Player i selects r; — $,| S Sameas S apart from us- Selects * — $, then an- 
computes ¢ from c, then ing é instead of c and swers according to 


runs P; with private in- a syntactic modification O(zr f). 


put 2;r; and common in- of strings handed over to 
put é. the adversary. 


Same as ©, but “turns 

off” to query of j, for 

some random j € [1..n]. 

Same as Q, but “turns 

off” to query of j, for 

some random j € [1..n]. 

S Same as ) Same as @, but returns a 
cept garbled program is “fake” garbled program, 
evaluated. having random strings 
for 3/4 of the gate labels. 


P Same as P, except out- | S Same as S, except sim- = O(€,7;f), the oracle 
puts the evaluation of the ulates the behavior of O for the simulator S. 


garbled program. using QO. 


Figure 4.1: A myriad of closely related protocols, simulators, and oracles. Omitted from 
the table are the oracles O;, for 0 < i <I, and the oracle O,. Only O and O are “true” 
oracles; the rest are probabilistic algorithms of c, £, #, f, and the oracle’s queries. 


with s%, defined from r; according to the equation of Step la(i) of the protocol P. The 
definition of C’ can then be read off the description of Step 1 of the protocol. 

We assume that c is encoded within the circuit C, so that not only is the map c+ é@ 
easily computed, but so to is the inverse map é+ ¢. 

Applying Theorem 4.1.1, Step 1 of P can be performed in polynomial-time and constant 
rounds. Since Step 2 requires polynomial-time and no communication at all, protocol P is 
a polynomial-time, constant-round protocol. 


DEFINITION oF §. Protocol P is an information-theoretically secure protocol for f. Let 
$= ($, AT, AO) be the simulator which establishes the security of P. Simulator S is given 
access to an oracle O = O( #7, 7; f). 

It is through S, AT, and AO that S, AT, and AO will be defined. Defining the 


functions AZ and AO is the easy part, so we dispense with it right off. 


DEFINITION OF AZ. The adversary input function for 5 is defined as follows: AZ(c,r) = x7 
when AZ(é,7) = xpr7. That is—after adjusting the common input in the same way that P 
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adjusts it for P—the adversary input function associated to S just “reads off” the adversary 
input as the appropriate substring of Al , applied to the same conversation. 


DEFINITION OF AO. As the adversary output function for $ specifies a garbled program, 
the natural thing is to define the adversary output function for S to simply evaluate that 
garbled program: thus AO(c,r) is defined as Eval(é, AO(é,T)). 


CONSTRUCTION OF S$, AT A GLANCE. In what way does § fail to be a good simulator 
for P? At a glance, 5 would seem to be a completely different beast from the simulator $ 
we wish to construct, because § has access to an O( 27, t; f)-oracle, while we only have 
access to an O(Z, 7; f)-oracle. 

All the same, the simulator S we define will behave very much like §. Except that 
whenever § would interact with its oracle O( #7, #; f); simulator S$ will interact with its 
oracle O(z,7; f), instead. From this, it will come up with a response of its own creation. 
For example, to a component query of i, the oracle won’t simply return the pair («;,7;), 
but some (2;7r;,7;), instead. In effect, we construct a “fake” oracle, O, which behaves like 
the “real” oracle, @. Oracle O is not really a “true” oracle at all, but a rather smart little 
probabilistic algorithm. 

This oracle substitution method is at the center of the proof described here. Because of 
the complexity of the arguments involved, oracle substitutions are described as being made 
in several stages. 

The O( 7, its f )-oracle, though not exactly (or even statistically) simulatable with only 
the aid of an O(%,7; f)-oracle, will be shown to be very closely approximable nonetheless. 
In fact, our approximation © to the oracle © will be such a good approximation that no 
polynomial-time test could tell with which of the two oracles it was conversing (as long as 
the polynomial-time test made fewer than n component queries to the oracle). In particular, 
the view provided to some polynomial-time t-adversary A when talking to the simulator $ 
running under O( 27, #; f ) will be computationally indistinguishable from the view provided 


to A when it speaks to the simulator 5 we construct running under the oracle O we devise. 


THE MEANING OF P’s privacy. The protocol P t-securely computes f in the information- 
theoretic sense. The privacy part of this assertion means that for any polynomial-time t- 
adversary A interacting with the network running P, the view A receives from the network 
is very closely approximated by interacting with the simulator S, instead. In symbols, 
and using the “shorthand” notation mentioned following the definitions of A-VIEW{ and 
A-VIEW, we have, by assumption, that 


EP a, #,a4,0) ~ ESCO EF #04, 0). (4.1) 


Equation 4.1 asserts statistical indistinguishability of L(f)-parameterized ensembles. We 


sometimes abbreviate statements like the one above to the less cumbersome €P, ~ €S@. 
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DEFINITION OF P. We define a protocol P “in between” protocols P and P. This helps us 
reason about P. 

Protocol P is identical to P apart from one matter: in protocol P, the garbled program 9 
which P computes is evaluated to a string y = Eval(é,%), and player i outputs y instead 
of 9. Protocol P does not do this; it simply outputs the garbled program 9. 

In other words, P instructs each player i to take his private input z; and his common 
input c, and replace his private input by 2;r; and replace his common input by ¢é, where 7; 
is i’s length-p prefix of coins. After this initial replacement, P instruct player i to behave 
as P dictates. 


DEFINITIONS OF § AND OQ. Paralleling the modification of P to P, we modify simulator $ 
to create a different simulator $, and modify oracle 0 to a make a different oracle O. 

We consider a probabilistic analog to the oracle O, which we call ©. Oracle O behaves 
as follows: it selects a random 7# — (D?)", and then behaves like O(Z7, 7; ran returning 
(2;7;,7;) to a component query of 7, and returning jr = f(zprh Uayrz) to an output query 
of zr}. 

The simulator S$ is very similar to the simulator S. It begins by mapping its common 
input c to the string é, and pretending, subsequently, that @ was the common input it was 
issued. Additionally, when a processor i is corrupted, simulator 5 would normally provide 
information to the adversary specifying the private input 2,7; of the corrupted processor, 
its history 7;, and its computational state s7°. Simulator $ answers identically, except that 
the private input of i is replaced by 2z;, and the computational state of i is syntactically 
modified so that r; specifies the coins that were initially flipped when player 7 executes P.? 


PROTOCOL P iS WELL-APPROXIMATED BY S°. We argue later that Equation 4.1 and our 
definitions of P, $, and O imply that 


EP,(#,#,a4,c) ~ ESO(#,#,a,4,c). (4.2) 


This is the content of Claim 4. Equation 4.2 asserts statistical indistinguishability of L(f)- 
parameterized ensembles. 


THE SIMULATOR §. When an adversary attacking the network running P corrupts a pro- 
cessor i in her final round, she discovers, encoded in i’s computational state, 2’s private 
output—the garbled program y. Simulator $ is obtained from S$ by replacing the string re- 
turned by S' in response to any final-round corruption by the corresponding string in which 
the specified output value, rather than being the garbled program 4, is the value y that 
this garbled program evaluates to. (For technical reasons—see page 89—we also demand 
“8G ace’ Pts a protocol we speedy (ie deseripuon of, there is no problem in determining how these coins 


are to be inserted in a description of the computational state so as to “look” like a computational state 
obtained from a processor running under P. 
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Figure 4.2: What the simulator § asks of its oracle O 


that S provides a distinguished forbidden-value to the adversary with which it speaks if $’s 
oracle returns a distinguished forbidden-value. Oracles © and O do not return forbidden.) 
We will later show (and it is pretty obvious, given Equation 4.2), that 


EP,(#,#,a4,c) ~ ESO(#,#,a4,c). (4.3) 


This is the content of Claim 5. Equation 4.3 asserts the statistical indistinguishability of 
L(f)-parameterized ensembles. 


THE ORACLE Q. So far, the modifications to P, $, and O have been simple, essentially 
“syntactic” modifications. In essence, we have simply set ourselves up to do something 
more interesting: to replace the oracle which knows about f with an oracle that only knows 
about f. That is, we will now replace the oracle © by a “fake” oracle Q, realizable given 
an oracle O = O(z,7;f). We now describe the behavior of O. 

Let us consider the sequence of queries that $ makes to its oracle ©, and describe how 
we will answer them with ©. See Figures 4.2 and 4.3. 

As with any simulator interacting with its ideal evaluation oracle, there are three phases 
of oracle queries: (1) the component queries; (2) the output query; and (3) additional 


component queries. 


83 


24 ay 


tj 


Cty. vy 
: : ota. 


tj4t itt 


te 


Figure 4.3: Alternatively, $’s queries can be answered by the “fake” oracle, O, which uses 
an O( 2,7; f) oracle to compose its answers. 


The oracle © begins by selecting a random # € (?)". To a component query of i 
(whether before or after the output query), © will make an oracle call to its O(#, 7; f)- 
oracle to learn x; and 7,; it will then return (2;7;, 7;). 

Note that the distribution on what © returns in Phase 1 and Phase 3 of the oracle 
queries is identical to the distribution that O returns for these queries. 

What remains is to describe how © answers an output query of 2/,r/p. 

The oracle ©, on receiving the output query rpry, makes a query of 2 to O(z7; f), 
receiving a string y € D’. The strings y, rp, rg, and additional random bits are used in 
constructing ©’s response 


Y= AA AA: Apo An AtoAt g? ene y! 


to the output query. The string y is called the fake garbled program, as opposed to the real 
garbled program, ¥, that oracle O returns. 

To construct the fake garbled program, define 7” = rp Urt and set 55,8); - an ey = 
ri [1:2kW], where |s%,| = &, fori € [1..n]. Define sf = s¥,.--s? b forw € [1..W],b€ {0,1}. 
What we have done is produce signals which are a proper “intermixing” of random strings 


with those strings which the output query zr} specifies. 
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A “random path” through the garbled circuit is selected by flipping a coin wv” for each 
wire w that is not an output wire, w[1..W — 1]. The fake garbled program, ¥, will be devised 
so that s%., will be the signal held for wire w when y is evaluated, for w € [1..W—I]. (Claim 3 
establishes that this is really so.) For an output wire w, y will be constructed so that the 
semantically correct signal will be held, SYtw—-(W—)]- For uniformity in notation, then, set 
bY = ylw — W +1] for each output wire w,w € [W —14 1..W]. 

The conditions specified by the last paragraph are simple to satisfy by the appropriate 
choice of fake input signals, a1...0"*, and a correct definition of just one of the four gate 
labels A%,, for each gate g. Namely, select fake garbled inputs of 


o” = 3” (4.4) 


for each input wire w. Then, to a gate g with left input wire a, right input wire 6, and 
output wire 7, define one of the four gate labels A’, for each gate g according to 


AY 


pope 


= Gyp(sas)® ++ OGye(sen) @ Gye(p)@-++OGpa(22p,) © str. (4.5) 


We have thus specified fake garbled input o!---o™ of the fake garbled program y, and we 
have specified, for each gate g, one of the four gate labels for g. All that remains unspecified 
in y are the remaining three gate labels of each gate g. Set all 30 of these A$,-values to be 
random strings of length nk + 1. 
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Having defined oracle © and the simulator S$, we have defined the simulator S$: 5 = 
S°@*S) is $°, except that the oracle responses we have imagined being provided from O 
are computed by S itself, with the aid of its O(#,7; f)-oracle. Notice that the responses 
of O are easily computable from the responses of © and some coin tosses. 


ORACLE © WELL-APPROXIMATES ORACLE ©. The main goal is to establish that 
ESO(Z,#,a4,c) & ES$O(#,#,a4,0). (4.6) 


This equation asserts computation indistinguishability of £(f)-parameterized ensembles. 
The right hand side is, by definition, €S°. 

Equation 4.6 is still rather awkward to argue directly, so we argue instead (Claim 6) 
that Equation 4.6 follows from 


ES0(#,#,a4,c) ~ ES°O(Z,i#,a4,¢). (4.7) 


for oracles O and O, which are very much like O and O, respectively. The difference is that 
each chooses a random j € [1..n] and, if there is ever a component query of j, it “shuts up,” 
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refusing to answer any more questions. Equation 4.7 will then be argued by contradiction 
(Claim 7), where assuming its falsity allows the breaking the pseudorandom generator G. 


SUMMARY OF STRATEGY. Before proceeding, we observe that, taken together, Equations 4.3 
and 4.6 imply that P is t-private. The global strategy for arguing privacy, can be described 
as: 


EP, (#7, #, a4, é) 
EP, (2, #,a4,¢) odin ESO (#, #,a4,¢) = 


EP(#,#,a,¢) = « ESO(Z,#,a4,¢) ci e7 E58 (Es F,045¢) = ESE (F, H,44,0)- 


6, 


Under each assertion is written the claim used to establish it. The “heart” of the proof— 
and the only arguments which really depends on the clever definition of the protocol P—is 
Claim 7, which begins on page 90. (On a first reading, it may be desirable to begin there.) 


Part 2: The simulator S establishes security. 


Claim 1: EVALUATING @ GIVES y 


We show that evaluating a (real) garbled program g gives the value y which it “should” 
evaluate to: for any 2p, rp, ap and rq, y = Eval(é, f(2,r, Uzgrp)) is equal to f(z), Urq). 
The argument is by induction on the depth of the circuit C defining f. We maintain the 
following invariant: if, in the evaluation of § = f(alprhp Uarryz), signal o” = s} is held for 
some wire w, then wire w carries the bit bBA” when C is evaluated at x7 U rz. Here, A” is 
defined from r = rj, Ury according to 


5 Of r,[2nW +] forw €{1.W—-—I], and 
~ (10 for w € (W —141..W], 


as with the equations of Steps la(i) and la(iv). 

The invariant is seen to hold for input wires, since the signal issued for an input wire w 
is o” = Sig), by Equation 3.2, and this wire carries a truth value of bY = (b°@A”)@A” 
in C, 

Inductively, consider a gate g of functionality ® having left incoming wire a (carrying a 
signal o* = s7.), right incoming wire @ (carrying a signal 0% = Bra); and out-going wire ¥. 
By Equation 3.4, the signal computed for wire y will be 


OF = Gye(Sioi)O-+* OGye(Sian) Guo(siai)® +++ PG ya (Shon) ® r. Wee 


which, from the definition of At a, Equation 3.3, is 


each chooses a random j € [1..n] and, if there is ever a component query of 7, it “shuts up,” 
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The inductive hypothesis says that the left incoming wire carries the bit w*@A°% in C, and 
the right incoming wire carries the bit u2@A*. So we know that out-going wire for gate g 
of C carries the bit (u°@A7) ® (u°@A°). Consequently, the signal 77 we have computed for 
wire 7 is 83,7, where wire ¥ carries the bit b in circuit C. This establishes the induction. 

By Equations 3.1 and 3.2, we conclude that Eval(g) = (O@A¥~'*1)..-(O@AW) =y 


Claim 2: PROTOCOL P IS CORRECT. 


We next argue that protocol P is correct. This follows from Claim 1 and definitions of AT 
and AO. 

The correctness of protocol P implies that, almost certainly, each player outputs 7 = 
f(xprp Urerp) as a result of the execution of Step 1, where 2/,r, is the adversary’s commit- 
tal in P, as specified by AZ.? In the protocol P, each player then computes his output y by 
evaluating this garbled program g. We need that the y-value so computed almost certainly 
equals f(z Uz), where zp is the adversary’s committal in protocol P. In fact, Claim 1 
establishes that whenever each good player computes 9 = f(2>rp Uarpr7), for any rp 
and rz, each player computes y = f(xp U az). Thus, almost certainly, each player, when 
running P, outputs y = f(x; U xm), where 2} is given by AZ and the output attributable 
to the adversary is given by AO. This establishes correctness. oO 


Claim 3: EVALUATING 9 GIVES y. 

Very similar to Claim 1, we show that, in evaluating the fake garbled program 4%, one 
comes to hold the signal s%. for each wire w. (By the same reasoning, “hybrid” garbled 
programs—where some of the off-path gate labels are meaningful and others are not—will 
share this property.) 

This holds by induction on the depth of the circuit C. For an input wire w, one holds s%. 
by the definition of o*, Equation (4.4). Inductively, from holding s%. for the left incoming 
wire of some gate g, and from holding st a for the right incoming wire of gate g, one computes 
and holds, according to Equation 3.3, 

OY = Gye( stay )B++ Gye (Shan) @ Gya(sie,)O-++OGye(Shen) @ Aleys 
for the out-going wire 7 of gate g. From the definition of Aj.,2, Equation (4.5), this is 
precisely s/\y. 

We conclude that Eval(y) = p¥~'+!...u”. By our choice of yw” values on output 
wires, Equation (4.3), this is precisely the string y returned from the oracle query O(27), 
y = fey Uap). 0 
Claim 4: EQUATION 4.2 IS CORRECT. 

Let A be a t-adversary. By the privacy of P, €P, ~ ESS, which is Equation 4.1. We wish 
to show that Equation 4.2 holds, that EP, ~ ESC. 


°That is, the good players do output the string g in Step 1, while the adversary could compute § by 
evaluating AO. 
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First note that, for any distinguisher D*, for a negligible function «(k’), 


e(k’ max IED r*, #,a,,6)) — ED($0 (a7, 7, 04,6 | 
(k’) gp ak (Pi ( As€)) (5, (27, 7, a4, é)) 
FE(DPC) re 


Q~ Pete ED(P,(#?,#,a,4,@)) — ED($0( #7, #,a4,¢ 
sneer el (P,(#?, #, a4, é)) (Sp (27,7, a4, »| 


Q- Pete D P a a = 
(toncleLy(s) gin, Be Male eyante) 


ai 
my 
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ts 
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UW 
SG 
Fen, 
gy 


, (4.8) 


Fr, F, Qa, é)) 


(Recall that D(E,(w)) is short for D(1*, E,(w),w,a), and k = min{k’, |c|‘/'°}.) That the 
first quantity is negligible follows directly from P’s privacy; the next inequality just says 
that the average of a bunch of elements can not exceed the maximum of these element; and 
the last line is the triangle inequality: >> |A; — B;| > |SO(A; — B;)| = [SD Ai — © Bil. 

Now, given a distinguisher D*—-think of this as having been designed for distinguishing 
EP, from €$0—given any such distinguisher, there is a distinguisher D* such that 


ED(1* , Py(Z, #,a4,¢),(@,7,a4,c),a) = 
gene SS" ED(1*, P.(ZF, #, 04, ¢), (ZF, 7, a4, é),0) (4.9) 


FE (Dee) 


and 


ED(1" , S0(2, #,a4,¢), (Z,#,a4,¢),@) = 
Q-rene S~ ED(1*, SP (a7, 7, aa, 6), (EF, 7, aa, 0),0). (4.10) 


FE(Lec)re 


Namely, the distinguisher D is defined as follows. It maps its first argument, k, to k’; it 
maps its third argument, (Z7, 7,a,,é), to (Z,7,a,4,c); it maps its fourth argument to itself; 
and it maps it second argument, which is the view @ of the adversary A, to an alternative 
view v, as follows: when ? indicates that a processor i is corrupted, and processor 2 had 
private input 2z,;7r;, the view v is constructed so that 2; is the private input and r; is the 
prefix of 2’s random string. That is, 7 is a syntactic modification of # so that it is a view 
that would appear to come from P, not P. After modifying the arguments in this way, 
the distinguisher D is applied to them. Equations 4.9 and 4.10 follow directly from the 
definitions of P, P,$,5,D, and D. 
Combining Equations 4.8, 4.9, and 4.10, we have that 


E(k’) > [ED( Pu, ,a4,C)) — ED(SO(z, , aa,c))| : 
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which is precisely Equation 4.2. Oo 


Claim 5: EQUATION 4.3 IS CORRECT. 


The last claim easily gives Equation 4.3. To see this, note that if €£,(w) ~ EF, (w) and h 
is any function, then Eh(E,(w)) ~ Eh(E,(w)). (Likewise, if EF, (w)e€E,(w) and h is 
efficiently computable, then Eh(E;(w)) ~ Eh( E,(w)).) 

More explicitly, the only difference between P and P is that P evaluates the garbled cir- 
cuit which has been collaboratively computed, outputting this evaluation, while P outputs 
the garbled program itself. Let A be a t-adversary. By our definition of P and P, 


P,(@, 7,a4,c) = eval( P,(Z, 7,a,4,¢)), (4.11) 


where eval is the function on views that simply replaces the string encoding A’s view with 
the identical string, except that the garbled program # which the view 7 specifies to be 
output is, instead, evaluated, with the function Eval; it is this string which v = eval(i) 


specifies should be output. Likewise, 
SO(#,#,a4,c) = eval(5S°(#,#,a,,c)), (4.12) 


as follows directly by the definition of S$ and §. Applying eval to both sides of Equation 4.2 
gives 


€ eval(P,(@,#,a4,c)) = € eval(SO(Z,7,a,,0)). 
Combining this with Equations 4.11 and 4.12 gives 
EP,(Z,%,a4,c) ~ ESO(#,#,a4,0), 
as desired. oO 
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DEFINITIONS OF © AND ©. We are now ready to address the main concern, that the “fake” 
oracle O provides a very close approximation to O—not in the information theoretic sense, 
as with all modifications made so far, but with respect to polynomial-time computation. 
Actually, it will be convenient to argue this indirectly, showing that O remains closely 
approximated by © even if each of these oracles “shut up” if you ask some particular 
randomly-chosen component query. Specifically, define © and © as identical to © and O, 
respectively, except that each oracle initially chooses a random j € [1..n] and then, to a 
component query of 7, O and © answer forbidden—rather than z;r;, as they otherwise 
would. Once © or © answers forbidden, they answer A on any subsequent queries. We now 


show that it suffices to show that O is well approximated by ©. 
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Claim 6: Ir $9 ~ $9, ruen $9 w §°, 
We may assume that $ always makes exactly ¢ component queries, since a simulator which 
makes fewer queries than that can always be modified to make exactly ¢ component queries, 
ignoring the unneeded responses. Notice that S inherits this property from Ss. 

To establish Claim 6, suppose for contradiction that 


So ow $8, (4.13) 
yet 
BO ogee GO: (4.14) 
Equation 4.14 means that there exists a polynomial-time t-adversary A, a polynomial-time 
distinguisher D* and a sequence {(@;, 7, @x, cx) € Li(f)} such that 
v(k) = [ED(SP (ae, Fe, an, ce)) — ED(SP (Ee, Fes Oe, cx) 


is nonnegligible. Henceforth we omit the arguments to the simulators, writing an equation 


like the one above as simply 
v(k) = [BD($2) - ED(S?),| 


We will contradict Equation 4.13. To do this, define a distinguisher D’, which is identical 
to D except that D outputs the bit 0 on views containing a distinguished forbidden-value. 
As mentioned on page 81, § provides A with a distinguished forbidden-value when §$’s oracle 
responds forbidden. Then 


ED'(S°) = Prob Ex does not get a forbidden] : 


E [D(S2)| $2 does not get a forbidden] (4.15) 
= Prob [i = [len]: ge does not ask component query i . 

ED(S°) (4.16) 
= (1-t/n) ED(S¢), (4.17) 


where Equation 4.15 holds by our extension of Dj, to 0 on forbidden, and 
E [D($2)| So does not get a forbidden| = ED(S°) 
follows because of $, making exactly t component queries. Similarly, we have 


ED'(S?) 


Prob [se does not get a forbidden] ‘ 
E [ D(SP )IS? does not get a forbidden] 


Prob i + [l..n]: Se does not ask component query i . 
ED(S?) 
(1 —t/n) ED(S?). 
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Thus 
|ED'(S?)-ED(S?)| = (1-t/n) v(k) 
2 v(k)/2 
is nonnegligible, contradicting Equation 4.13 and establishing Claim 6. oO 


Claim 7: S° x §°. 


Finally, we address the heart of the matter. Proceeding by contradiction, assume that. 
5° £ $°. (4.18) 


This means that there is a polynomial-time t-adversary A, a polynomial-time distinguisher 
D*, a sequence {(Z;, 7, (a@a)z, cz) € Ly(f)}, a polynomial Q(k), and an infinite set K C N 
such that 


|ED(SP) - ED(S?)| > (4.19) 


1 
Q(é) 
fork € K. 

We will use this to construct a probabilistic polynomial-time distinguisher (D’)* for 
distinguishing the ensembles 


ER; = E(Uonks2)? and EPR, = €(G(Ux))’, 


where G : =F — D(**+1) is the pseudorandom generator used by protocol P. Recall that 
n = k'° is a bound on the size of n in terms of the associated security parameter k. The 
existence of such a distinguisher contradicts Lemma 4.2.3. 

To describe D’ and a’, fix k € K and let = %, 7 = He, a4 = (Ga), and c = cy. Let 
n,£,l,m,C,T, and p all be as indicated by ec. 

The distinguisher D’ takes as inputs the two strings, A’, B’ € ©?"*+?. It uses a substring 
of each of these strings to compute a “good guess” as to whether A and B are random or 
pseudorandom. Let Ap = A’[1:nk +1], Ay = A'[nk+2:nk + nk 4+ 2], Bo = B’[i:nk + 1], 
and B, = B'[nk + 2:nk + nk + 2]. 


DEFINITION OF THE ORACLE O;. We define a sequence of oracles, Oo, O1,..., Or, the first 
oracle will be identical to ©, and each oracle will be successively more and more like O, 
until Op = O. This might be depicted as 


O0=020,5°-:-3071>07=0. 


Passing from oracle O,_; to oracle O, can be thought of as “fixing up” the gate labels 
on gate g. That is, recall that O provides “meaningless” (random) gate labels on three 
of the four gate labels per gate, while Oo provides “correct” gate labels throughout. The 
intermediate oracles have meaningful gate labels on more and more gates. 
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The behavior of O; is as follows. The oracle begins by selecting a random 7 € (L?)” 
and a random j € [1..n]. To a component query of j7, O; responds with forbidden, and it 
responds with A to all queries following a forbidden response. Otherwise, to a component 
query of ue O; responds with z,r,. 

We must describe how QO; answers an output query of xr, returning some string 


~ al gl gl gl Tar gr gt pt... ane 
Y= AppAgAioAi +++ Apo An1 Aton o °°” 


which we now define. 
Exactly paralleling the definitions in the protocol and in the description of O, define 

7’ = ry Urz, and set 
S:81; °° Soy Shy rN; a ie =r; 


a? 


for i € [1..n], |s¥.| = &. For w € [1..W], declare 


yw af MOO ifwell.W-T, and 
~ 10 ifw € [W —141..W], 


and set sf = s¥,--- sf, b. Let b” be the value carried by wire w of C when C is evaluated at 
xp Uay, and define pw’ = AX Ob". 

Now to answer the output query, set o” = s4., for w € [1..né]. This defines the garbled 
input. To define the gate labels, for a gate g of functionality @, left incoming wire a, right 


incoming wire G, and out-going wire 7, define A’, according to 


G83, )® nee @G4(s%,,) @ 
Ga(shi)® aa @Ga(sh,) ® 


9 7 
Aas S[(a@A*)@(b@AP OAT 


if g € [1..7] or ab = pt p? (4.20) 
R3, otherwise 


where R%, is a randomly selected string from U"*+?, 

Informally, we have put in correct gate-labels for all gates numbered 1,...,7, and we 
have also put in correct on-path gate labels for the remaining gates. The other 3(IT — 7) 
gate-labels are garbage—just random strings. 


Claim 8: O = Or. 


This claim means that © and Op exhibit exactly the same (probabilistic) behavior when 
used as ideal evaluation oracles which are asked at most t component queries. 

This statement is immediate from the definitions of of O and Op. Both oracles choose 
a random 7 € [1..n], and answer forbidden to a component query of 7, answering A subse- 
quently. Apart from that, both oracles return 2;r; (for a random r;) to a component query 
of 7. To an output query of zpr>, both oracles return f(zprt Uapry). oO 
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Claim 9: 0 = Qp. 


This claim means that © and Op exhibit exactly the same (probabilistic) behavior when 
used as ideal evaluation oracles which are asked at most tf component queries. 

As before, both oracles choose a random j € [1..n], and answer forbidden to a component 
query of 7, answering A subsequently. Both oracles then choose a random 7, and, to a 
component query of 2, each answers 2;7;. 

To an output query of 2/,rj,, the oracle © chooses a random path p',...,u¥-' and 
returns a random fake garbled program y that computes f(z, U2) along this path, having 
random off-path gate labels. On the other hand, O; explicitly chooses no such random path; 


lt 


the path is implicitly specified by the 7”-values. 

Still, the path chosen, being a function of the randomly selected @77r;-values, is inde- 
pendent of the values returned by the ¢ < n component queries. Furthermore, the path 
does not depend on the output query itself. Thus both oracle © and Op answer an output 
query zpry by arandom path computing f(x; U ze), with Un,41-distributed off-path gate 
labels. This establishes Claim 9 oO 


Claim 10: THERE Is A g, €[1...°] SUCH THAT |ED(Sp""") ~ED(S?*) 


21/TQ(k). 

The claim follows immediately from Claims 8, 9, Equation 4.19, and the triangle inequality. 
In common parlance, we have taken a “probability walk” through the oracles Op > O1 > 
+++ => Op_, > Or. The distinguishing probabilities differ at the two endpoints; somewhere, 
there must be a nonnegligible “jump” in the distinguishing probabilities. We have let 9g, 
denote a place in which there is a jump between the behavior induced by oracles O,,_1 
and O,,. The same proof technique was used in the proof of Proposition 4.2.2. oO 


Ge PO ® 


Before proceeding, we make the following definition: a,, 3,, and 7, denote the left incoming 


wire, right incoming wire, and out-going wire to gate g;, respectively. 


THE ORACLE O,.* The distinguisher D’, recall, takes a string AoA, BoB, € D4**+) (ex- 
tracted from A’B’). Consider the oracle O., whose behavior depends on such a string 
AoA; Bo Bi, defined to behave as follows: it flips coins to determine the values j, 7, and R%,, 
exactly as O,, did before. Component queries are answered as O,, would answer them. 
Then, to an output query of zr, the values 7”, s¥., AY, A”, sf, bY”, w” and o” are all com- 
puted as O,, would compute these values. However, in forming the garbled program y,, 
the Aj,-values are computed differently than they were for O,,—but just for the case of 


“Introduced for the benefit of readers who believe there have not been enough oracles described in this 
proof. 
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gate g,. Namely, set 


Gs( sf, )B +--+ GGs(so,) © 
Ga(8p1)@ -+- BGa(s),) ® 


Aas = ) Siaeasje(oer? yen» if g € [1..gx] or ab = wp? (4.21) 
Ri, otherwise 
where 
Ag ifw =a, andi=j and 6 =p 
Ga(ss;) = Bg if w = §, and i=j and 6 = pe 


Gig(s%;) otherwise 


for 8,6 € {0,1}. We can describe the preceding as follows. Player j’s contribution to the left 
wire feeding gate g, is AyA; for the (supposed) generator output corresponding to the off- 
path signal. For the right wire, his contribution is By B, for the (supposed) generator output 
corresponding to the off-path signal. Now if Ay A; and B)B, really are pseudorandom, this 
is what player 7 should contribute for these wires, and we will compute a meaningful set 
of off-path gate labels for this gate. But if Aj A, and BoB, are truly random, then this 
contribution will cause all of the off-path gate labels to be random. We formalize this as 


follows: 


Claim 11: Ir A’ AND B’ ARE G(U;)-DISTRIBUTED, THEN Of04150%: = ©. 
Claim 12: Ir A’ AND B’ ARE Ucarg2)-DISTRIBUTED, THEN OA04:5oF1 = OQ, _). 


The first of the these two claims is immediate. The only concern is that a component query 
would necessitate revealing a preimage under the generator of an A or B-value. We don’t 
have any such values to reveal. Fortunately, we have arranged that a component query of j 
need only return a value of the response forbidden. 

The second of the these claims is just a little more complicated. The behavior of O, 
and O,,-; potentially differ only by the gate labels associated to gate g,. In O,,-1, random 
strings are used for the three off-path gate labels. In O,, on the other hand, the three 
off-path gate labels are produced according to Equation 4.21. The calculation of these gate 
labels can be viewed as XOR-ing three ©"*+!-valued random variables, X,;, Xj, and X3, 
with random variables Ay, Bo, and Aj, respectively, where Xo, X,, and X» are independent 
of Ap, Bo, and A, respectively. Thus, when A’ and B’ are Uoq,42-distributed, the three 
off-path gate-labels are U,441-distributed. oO 


WRAPPING UP. We now complete the proof of Claim 7. Observe that, given Z, 7,a4,c and 
gx, and given A and B, it is easy to compute a sample from $°* in time polynomial in |e]. 
The distinguisher D’, using advice which encodes both the (infinite collection) of strings 


a’ = {(&k, 7, (Ga )e, Ck, ge)} and the infinite string a in a reasonable manner, and using A 
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and B, works as follows: it computes a sample v from $2" and then computes the bit 
D(1*,v, (Ze, ®e,(Ga)e,Ce),@). It output this bit. We know that 


: ; 1 1 
[ED'(Rx) —ED'(PR,x)| 2 T,Q() 2 FOO(R) 


for all k € K. This contradicts the assumption given by Equation 4.18, and so have 
established Claim 7, as well as the Theorem 4.3.1. gO 
a 


4.4 Postmortem 
We begin with a few comments about the proof of Theorem 4.3.1. 


REQUIREMENT ON HONEST MAJORITY. The assumption that t < n/2 was only required 
because Theorem 4.1.1 requires this; a garbled program reveals no useful information as 
long as t < n. Indeed, the proof we have given remains unmodified to establish this claim, 
apart from relaxing the bound in the conclusion of Claim 6 to “> v(k)/n > v(k)/k!°.” 


GENERALITY OF TECHNIQUES. Some of the techniques used in the proof of Theorem 4.3.1 
are applicable to other simulator arguments. One of these methods is considering the 
probabilistic analog of deterministic protocols and simulators, as we did in passing from P 
to P and from © to O. Another is considering oracles which “shut up” when asked oracle 
queries they find inconvenient to answer. The high-level method of replacing one oracle by 
another—the “oracle substitution argument” we have employed—is likely to be generally 


applicable. 


VECTOR-VALUED SECURE COMPUTATION. For simplicity, we have described the protocol 
for string-valued computation. There is no difficulty extending the protocol to vector valued 
computation, and there is no difficulty carrying the proof over to this case, as well. 

To collaboratively compute a vector-valued function f : (Z°)" — (Z')", the players 
compute, instead, a string-valued function f, : (Ut')" = DO”, defined by y = f.(@7) = 
(ri@fi(Z))--- (ta @fn(Z)). To compute f, each player is instructed to choose a random 
r; € ' and then run the protocol for securely computing f,. Then, each player 7 outputs 
yi = ry. [(@ — 1)1 +1: il]. Using this method, the following extension of Theorem 4.3.1 
can be obtained: 


Theorem 4.4.1 (Main theorem—vector-valued computation) Assume a one-way 
function exists, and let f = {f,} be a vector-valued function family in which each 
f. : (D*)"* — (Z'e)" is described by a circuit C, for computing it. Then, for some absolute 
constant R, there is a polynomial-time, R-round protocol P that t-securely computes f, 
where t = |(n — 1)/2]. a 
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